Что мы имеем на третьем уровне…
Модель еТОМ состоит (см. рис.1) из трех областей: “Стратегия, Инфраструктура, Продукт”, “Операционные (производственные) процессы” и “Управление предприятием”, каждая из которых имеет многоуровневую иерархическую структуру декомпозиции бизнес-процессов от концептуального (нулевого) до достаточно детализированного (третьего) уровня. На этом заканчивается стандартная часть еТОМ. Дальнейшая декомпозиция бизнес-процессов потребует уже данных о структуре, возможностях и особенностях конкретного предприятия Телекома, что можно и следует делать уже на предприятии, желающим разобраться со своими бизнес-процессами, в рамках консалтинг-проекта. А именно: упорядочить, модернизировать бизнес-процессы, привести их в соответствие с общепризнанными рекомендациями, которые и воплотились в стандарте еТОМ.
См. .
Приведем в качестве примера в нашем переводе фрагменты описания трех процессов, находящихся на 2-м и 3-м уровне еТОМ :
2-й уровень области “Операционные Процессы” слой “Сетевая эксплуатация и управление ресурсами”: "Resource Performance Management" ("Управление производительностью ресурсов")
Код процесса OPS 3-4.
"Resource Performance Management processes encompass monitoring, analyzing, controlling and reporting on the performance of resources. They work with basic information received from the Resource Data Collection & Processing processes. If the analysis identifies a resource quality problem, information will be passed to Resource Trouble Management and/or Service Quality Management."
[ “Процессы "Управления производительностью ресурсов" проводят мониторинг, анализ, управление и составляют отчеты о производительности ресурсов. Они работают с исходной информацией, получаемой из процессов "Накопления и обработки данных о ресурсах". Если анализ выявляет проблему качества ресурса, то информация будет передана в процесс "Управление проблемами ресурсов" и/или в "Управление качеством услуги" и т.д. ]
3-й уровень декомпозиции:
"Analyze Resource Performance" (“Анализ показателей производительности ресурсов”)
Код процесса 1.OPS.3.4.2
" The objective of the Analyze Resource Performance processes is to analyze the information received from Resource Data Collection & Processing in order to evaluate the performance of the resource and report the findings of this analysis. This also includes further analysis of the performance anomalies identified by the Monitor Resource Performance processes."
[ “Назначение процессов “Анализа показателей производительности ресурсов” состоит в анализе информации, полученной от “Накопления и обработки данных о ресурсах”, чтобы оценить производительность ресурсов и сообщить результаты этого анализа. Сюда также включается дальнейший анализ выявленных процессами “Отслеживание показателей производительности ресурсов” нарушений производительности” и т.д. ].
"Control Resource Performance" (“Контроль показателей производительности ресурсов”)
Код процесса 1.OPS.3.4.3
"The objective of the Control Resource Performance processes is to apply controls to resources in order to optimize the resource performance. The need for installing performance controls can be identified by the Analyze Resource Performance processes or requested by the Service Quality Management processes. This also includes the instantiation of pre-plans, which have been defined in order to cope with abnormal situations caused by, for example, natural disasters or mass calling events."
[ “Назначение процессов “Контроль показателей производительности ресурсов” состоит в применении управляющих действий для оптимизации производительности ресурсов. Потребность в применении контроля производительности может быть выявлена процессами “Анализ показателей производительности ресурсов” или по требованию процессов "Управления Качеством Услуги”. Сюда также включается реализация предварительных планов действий в аварийных ситуациях, вызванными, например, стихийными бедствиями или лавинообразным потоком звонков” и т.д.] .
Из этих описаний видно, что на нижнем (третьем) уровне декомпозиции еТОМ перечисляет необходимые действия, связывая их с другими процессами в рамках единой модели. Не более того, но и это уже очень существенно, так как позволяет проанализировать:
наличие/отсутствие названных действий на конкретном Телеком-предприятии; почему отсутствуют или, наоборот, выявлены дополнительные действия; является ли это достоинством или недостатком системы управления конкретного предприятия
Отметим, что многоуровневая иерархическая структура еТОМ позволяет решать не всю сразу задачу моделирования системы управления всего предприятия, но выделить, как ветвь иерархии бизнес-процессов, отдельную крупную задачу (или несколько задач), которой требуется заняться в первую очередь. Стандартное (то есть, быстрое и единообразное) описание всех бизнес-процессов до уровня сбора и анализа конкретной информации предприятия (то есть, информация для бизнес-процессов 0-3 уровней декомпозиции) обеспечивает как существенную экономию сил и времени на первом этапе моделирования, так и позволяет использовать эти же наработки для разработки всех следующих проблем управления Телеком-предприятия. Собственно говоря, в этом и состоит основное значение любого стандарта, и еТОМ, в частности.
Заметим, что декомпозиция бизнес-процессов области “Управление предприятием” завершается на втором уровне именно потому, что процессы этой области не несут столь определенной направленности на бизнес-процессы именно Телекома и могут пригодиться в любой индустрии. Тем самым, идеология и технология модели еТОМ хорошо применимы при бизнес-моделировании управления многих и многих типов предприятий.
Литература:
“eTOM Overview”, TeleMagement Forum, http://www.tmforum.org/browse.asp?catID=1648 ITU-T. TELECOMMUNICATION STANDARDIZATION SECTOR. (06/2004). Telecommunications management network. Enhanced Telecom Operations Map® (eTOM) – The business process framework. M3050.1 @ ITU 2004
[3]Е.Нагаев “еТОМ: структурная модель бизнес-процессов для операторов связи”, М:, 2Мобильные системы”, 5, 2005. “Enhanced Telecom Operations Map (eTOM) The Business Process Framework” Addendum D: Process Decompositions and Descriptions (For The Information and Communications Services Industry), www.tmforum.com, GB921D_v4-0-1_040318.pdf Mike Kelly (TeleManagement Forum) “NGOSS and eTOM”, November 2002, Free Download. Telecargar Document. Formato. Talla. Colocado. Free Download. http://www.itu.int/itudoc/itu-t/com2/infodocs/019_pp7.ppt Steve Cox (Sr. Director NAS Applications Business Unit, Oracle Corporation) “Leveraging the ETOM To Facilitate Your Business”, Telemamagment World, Nice, May 19-22, 2003, http://www.tmforum.com/browse.asp?articleID=23012 Martin Huddleston (Principal Engineer, QinetiQ) “From ITIL to eTOM: Gluing Together the eProcess Value Chain In Mixed Civil/Military Environments”, 2002, TMFC1132 OSSBIZ4 Martin Huddleston and Nigel Phillips ver2.ppt, http://www.tmforum.org/browse.asp? catID=1207&sNode=1207&Exp=Y&linkID=25663&docID=1132
Начнем с себя…
Хорошо известно, что информатизация управления не приносит заявляемых и ожидаемых результатов в условиях слабой или отсутствия конкуренции, при наличии дешевых или практически бесплатных ресурсов. Как анекдот, известно высказывание руководителя одной Большой компании, что он с лихвой покроет все будущие денежные результаты от информатизации, продав сегодня пару дополнительных составов природного сырья, и что это ему почти ничего стоит. Истинная информатизация управления связана с новыми вложениями в вычислительную технику и программное обеспечение, с привлечением высококвалифицированных и, следовательно, дорогих специалистов, с переобучением своих сотрудников и ломкой сложившихся стереотипов поведения, деятельности и т.д. А результат всей этой деятельности может проявиться и не скоро, и неизвестно, будет ли он таким, каким сегодня мыслится инициаторам.
Но делать что-то надо. Старый лозунг “АСУ – веление времени” - не просто лозунг, а, действительно, веление времени. Как только действенность хотя бы одного фактора (слабая конкуренция и/или дешевизна ресурсов) существенно падает, так падает и поток доходов. Оказывается, что модель экстенсивного развития более не работает, имеющаяся система управления, хотя численно разбухла, но уже не обеспечивает скорость, качество и цели управления и начинает расходовать на свое содержание больше ресурсов, чем производит производство. Единственный выход – переход на модель интенсивного развития, которая предполагает, в том числе, исследование и модернизацию бизнес-процессов управления предприятием.
Одной из наиболее известных современных многоуровневых моделей бизнес-процессов управления производством – это eTOM (Enhanced Telecom Operations Map – расширенная модель деятельности Телекома), разработанная международной некоммерческой организацией TeleManagement Forum (TMF) . С апреля 2004г. eTOM 4.0 становится стандартом – так принял Комитет по телекоммуникационным стандартам (Telecommunication Standardization Sector (ITU-T)) Международный Союз Связи (ITU - International Telecommunication Union) .
На представлен первый уровень иерархии (всего их четыре: 0 – 3) декомпозиции бизнес-процессов [1, 3].
Переход к программно-информационным структурам…
По нашему представлению, еТОМ (на любом, даже самом детализированном уровне декомпозиции бизнес-процессов) представляет собой логически-имитационную модель деятельности предприятия. Для того, чтобы она заработала в режиме АСУ, ее надо воплотить в программно-информационную структуру. Это можно сделать разными путями, например, разработав схему базы данных, построив требуемые приложения и т.п. Но можно воспользоваться готовыми приложениями, оценив только, насколько они отвечают выполненному проекту, и настроить имеющиеся и разработать только недостающие приложения. Такой путь предлагает полнофункциональный комплекс приложений уровня предприятия Oracle E-Business-Suite, в котором имеются необходимые программные компоненты для реализации модели еТОМ на предприятии Телекома .
Предложение и привязка компонентов Oracle E-Business-Suite к уровням и процессам модели еТОМ:
Основные программные системы Oracle E-Business-Suite для индустрии коммуникаций Отображение модели еТОМ на решения Oracle для промышленности
Почему Телеком...
В промышленности связи, в сфере телекоммуникаций за последние несколько десятков лет наблюдалось настолько бурное развитие, что, можно сказать, отрасль претерпела ряд действительно революционные изменения, поскольку направление электронных коммуникаций поднялось почти от нуля. Естественно, это было связано с общественным, с бизнес-спросом на увеличение объемов передаваемой информации, на повышение скорости и качества ее переработки.
Но немалую роль сыграла и специфика ориентированной на высокотехнологичные услуги телекоммуникационной отрасли. Для нее характерна относительно малая материало- и повышенная науко- емкость. В ней широко применяется высококвалифицированный (дорогой) и сравнительно мало – низкоквалифицированный (дешевый) труд. Нематериальный характер конечной продукции позволяет избежать больших капитальных вложений в производство, что обуславливает достаточно высокий уровень и быстроту возврата инвестиций, прибыльность и прочие позитивные макроэкономические показатели. “Платой” за такие уникальные условия стало требование быстрой модернизации в ответ на все возрастающие потребности общества и бизнеса в информации, скорости и объемах ее получения. Новейшие способы совершенствования сетей, интеграция технологий и различного телекоммуникационного оборудования, создание мультисервисных сетей следующего поколения, беспроводные способы передачи данных и многое другое – без этого трудно выжить на рынке.
Жесткая конкуренция, высокая изменчивость, многоплановость и многообразие, быстрота предоставления услуг,… - неизбежно отражаются на системе управления предприятия Телекома, на (это - решающий фактор (!)) скорости, правильности, полноте принятия решений, на необходимом прогнозе конкуренции, партнерства, развития потребностей пользователей и рынка и т.п.
Это - общие для всех Телеком-предприятий задачи, которые воплощены в повседневные бизнес-процессы управления. Отметим, что многие бизнес-процессы характерны и существуют для многих-многих других отраслей бизнеса. Но Телеком в лице TeleManagement Forum (TMF), объединяющего около 400 компаний по всему миру, в том числе, и операторов связи, в данном случае оказался одним из первых, возведя в ранг международного стандарта модель еТОМ.
Подытожим…
Использование еТОМ дает: экономию времени и затрат на разработку структуры бизнес-процессов предприятия решение типичных задач анализа и оптимизации бизнес-процессов
выявление и устранение дублирующих процессов, имеющих одинаковую функциональность ускорение разработки новых процессов основу для управления набором ИТ-приложений, исходя из потребностей бизнеса возможность создания четких и качественных моделей потоков бизнес-процессов. дальнейшее применение знаний в области бизнес-процессов.
Применение технологии еТОМ на многих предприятиях Телекома дает возможность интегрировать между собой многие бизнес-процессы нескольких предприятиях, являющихся поставщиками-партнерами друг друга или объединенных другими связями. На показано, как взаимодействуют между собой бизнес-процессы разных Телеком-предприятий, применяющих модель еТОМ, причем эти взаимодействия можно автоматизировать, доведя их в идеале до уровня баз данных.
Положительный эффект от использования еТОМ ощутим не только для Телеком-компаний, но также и для софтвер-компаний, разработчиков систем класса OSS/BSS, системных интеграторов и др. еТОМ используют Oracle, Amdocs, Agilent Technologies. Примером реализации еТОМ может служить разработка глобальной ИТ-архитектуры Vodafone, в основу которой была положена структура еТОМ, адаптированная и отражающая специфику компании.
По мере развития сферы телекоммуникаций в России проблема комплексного анализа и оптимизации бизнес-процессов, операторов связи становится все более актуальной. Соответственно возрастает ценность и значимость как всей программы по развитию структуры NGOSS, так и ее бизнес-составляющей eTOM. В России в настоящее время модель структуры бизнес-процессов еТОМ в реализации Casewise Corporate Modeler поставляет только “ФОРС –Центр Разработки”.
Следующий шаг – NGOSS
Пирамида управления предприятием Телекома, представленная в левом верхнем углу (сверху вниз – управление бизнесом, услугами, сетью и элементами сети) воплощается в модель производственных (операционных) процессов ТОМ (Telecom Operations Map), которая расширяется до еТОМ - бизнес-модели процессов управления Телеком-предприятия в целом, которую TMForum собирается воплотить в проект NGOSS (New Generation Operations Systems & Software), который позиционируется как обобщенная и интегрированная структура для создания эффективного комплекса систем класса BSS/OSS и другого программного обеспечения .
Структура NGOSS представляет собой четыре различные, взаимосвязанные между собою компоненты, а именно:
Анализ бизнес-процессов Анализ и проектирование систем Анализ и проектирование решений Анализ на соответствие
Тем самым, миссия NGOSS - интеграция в единую архитектуру технических и бизнес-аспектов деятельности Телеком-компаний, устранение разрозненности и "лоскутности" автоматизации, построение общей информационной инфраструктуры. Структура NGOSS используется в деятельности таких крупнейших провайдеров как Vodafone, Verizon, Telstra, Telecom Italia, TeliaSonera, China Telecom и др. Главным компонентом NGOSS является механизм анализа бизнес-процессов, а именно eTOM.
Телеком – модель бизнес-процессов – eTOM – Oracle
А.В.Бачин
Источник:
Чтобы победить,
надо знать себя и противника.
Карл фон Клаузевиц
(и, наверное, не только он)
Функции типа данных TIME
Приведу пример использования нескольких функций, их декларацию можно посмотреть в спецификации пакета DBMS_STANDARD.
Листинг 3
SCOTT@O102>alter session set nls_time_format='HH24:MI:SSXFF'; Session altered. SCOTT@O102>alter session set nls_time_tz_format='HH24:MI:SSXFF TZH:TZM'; Session altered. SCOTT@O102>col tm for a40 SCOTT@O102> --CURRENT_TIME - текущее время с временной зоной SCOTT@O102>select current_time tm from dual; TM ---------------------------------------- 02:22:34 +06:00 SCOTT@O102> --LOCALTIME - локальное время SCOTT@O102>select localtime tm from dual; TM ---------------------------------------- 02:23:29 SCOTT@O102>
--TO_TIME - преобразование строки к типу TIME, опциональный второй аргумент - NLS-format SCOTT@O102>select to_time('01.02.03','hh24.mi.ss') tm from dual; TM ---------------------------------------- 01:02:03.000000000 SCOTT@O102> --TO_TIME_TZ - аналогичен TO_TIME, но возвращает TIME WITH TIME ZON SCOTT@O102>select to_time_tz('01.02.03','hh24.mi.ss') tm from dual; TM ---------------------------------------- 01:02:03.000000000 +06:00 SCOTT@O102> --EXTRACT - действие, как и для прочих DATETIME типов данных SCOTT@O102>col hour for 9999 SCOTT@O102>col min for 999 SCOTT@O102>col sec for 90.999999999 SCOTT@O102>with t as (select to_time('01.02.03.123456789','hh24.mi.ssxff') tm 2 from dual) 3 select extract (hour from tm) hour, 4 extract (minute from tm) min, 5 extract (second from tm) sec 6 from t 7 / HOUR MIN SEC ----- ---- ------------- 1 2 3.123456789 SCOTT@O102> --TO_CHAR - аналогична TO_CHAR (datetime) SCOTT@O102>col tm for a20 SCOTT@O102>select to_char(current_time,'hh-mi AM "TZ" TZH:TZM') tm from dual; TM -------------------- 09-06 PM TZ +06:00
Использование с другими типами данных
В заключении, приведем таблицу операций, которые мне удалось обнаружить над типом данных TIME.
Листинг 4
| TIME | - | TIME | DSINTERVAL |
| TIME | + | DSINTERVAL | TIME |
| TIME | - | DSINTERVAL | TIME |
Как включить тип данных TIME
Включение использования типа данных TIME можно добиться установкой события 10407 на уровне сессии. Без включения данного события тип данных TIME остается заблокированным, и все обращения к нему или к зависимым функциям будут заканчиваться различными ошибками. Ниже приведен листинг включения данного события и создания таблицы с единственным полем типа данных TIME(0).
Листинг 1
SCOTT@O102>exec dbms_output.put_line (sqlerrm(-10407)); ORA-10407: enable datetime TIME datatype creation PL/SQL procedure successfully completed. SCOTT@O102> --Create table with time datatype SCOTT@O102>create table t (tm time); create table t (tm time) * ERROR at line 1: ORA-00902: invalid datatype SCOTT@O102> --Set event 10407 and try again SCOTT@O102>alter session set events '10407 trace name context forever, level 1';
Session altered. SCOTT@O102>create table t (tm time); Table created. SCOTT@O102>desc t Name Null? Type ----------------------------------------- -------- ------------------------- TM TIME(0) SCOTT@O102>insert into t select to_time('01.02.'level*5) from dual connect by level<=5; 5 rows created. SCOTT@O102>select * from t; TM --------------------------------------------------------------------------- 01.02.05 AM 01.02.10 AM 01.02.15 AM 01.02.20 AM 01.02.25 AM
В паре к типу данных TIME, существует тип данных TIME WITH TIME ZONE, который дополнительно хранит еще часы и минуты временной зоны. Если обратить внимание, то на самом деле мы в предыдущем примере создали таблицу типа данных TIME (0) – в текущей реализации тип данных TIME может хранить и доли, меньшие секунды. То есть TIME (n) служит для хранения: часов, минут, секунд и 10n
долей секунды (где n – целое от 0 до 9).
Связанные NLS-параметры
NLS-параметры, связанные с типом данных TIME, подчиняются абсолютно тем же правилам, что и прочие NLS-параметры (типов DATE, TIMESTAMP и т.д.). Как мне известно, есть всего два таких NLS-параметра: первый для TIME, второй для TIME WITH TIME ZONE. Рассмотрим небольшой пример.
Листинг 2
SCOTT@O102>col parameter for a30 SCOTT@O102>col value for a30 SCOTT@O102>select * from nls_session_parameters where parameter like '%TIME\_%' escape '\'; PARAMETER VALUE ------------------------------ ------------------------------ NLS_TIME_FORMAT HH.MI.SSXFF AM NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR SCOTT@O102>desc t1 Name Null? Type ----------------------------------------- -------- ------------------------- TM TIME(6) SCOTT@O102>select * from t1; TM --------------------------------------------------------------------------- 01.02.03.456789 AM SCOTT@O102>alter session set nls_time_format='HH24:MI:SSXFF'; Session altered. SCOTT@O102>select * from t1; TM --------------------------------------------------------------------------- 01:02:03.456789
Тип данных TIME
М.Великих
инженер ЦТП Oracle
компания "АйТи"
г.Новосибирск
В данной статье хотелось бы
В данной статье хотелось бы рассказать про недокументированный тип данных TIME, реализованный в Oracle. Новички в Oracle часто забывают, что тип данных DATE также содержит время, иногда пытаются создавать свои типы данных для хранения именно времени или вовсе хранят время в строковых типах данных (CHAR, VARCHAR2). В мои цели не входит обсуждение того, почему корпорация Oracle до сих пор официально не разрешает этот тип данных и не включает его в последующие релизы Oracle Server, я только покажу, как это работает. По моим данным, тип данных TIME существует в Oracle, начиная с версии 8.1.6, т.е. уже достаточно давно, все это время оставаясь сокрытым от широкой общественности, хотя упоминание некоторых с ним связанных функций легко обнаружить в пакете DBMS_STANDARD. Все проведенные эксперименты проверялись с незначительными оговорками на версиях 8.1.7.4, 9.2.0.7, 10.2.0.1. Итак, приступим.
Конфигурирование Active-Standby pair репликации и Oracle Clusterware
Ограничения: В данном примере описывается создание простой конфигурации (basic level of availability).
Вначале добавим сущность в cluster.oracle.ini, в которой пропишем узлы, на которых будет запущена репликация, и директорию для CRS-скриптов (check, start, stop) для определенной репликации). … [ha_ds] MasterHosts=rac1,rac2 ScriptInstallDir=/u01/app/oracle/product/11.2.1/TimesTen/tt1/info/crs_scripts …
Теперь нужно повторить настройки cluster.oracle.ini и sys.odbc.ini на втором узле (rac2).
Далее регистрируем TimesTen кластер в OCR.
[root@rac1 ~]$ cd /u01/app/oracle/product/11.2.1/TimesTen/tt1/bin/
[root@rac1 bin]$ ./ttCWAdmin -ocrconfig
Oracle Clusterware home = /u01/app/oracle/product/11.1.0/crs
Далее запускаем агенты кластера TimesTen на обоих узлах. [root@rac1 bin]$ ./ttCWAdmin -init
Oracle Clusterware home = /u01/app/oracle/product/11.2.1/crs, hosts = rac1,rac2 =============================================================== Registering agent resources:... Registration complete. =============================================================== =============================================================== Registering daemon resources:... Registration complete. ===============================================================
После этого в CRS должны появиться четыре новых сервиса.
[oracle@rac1 ~]$ crs_stat -t
Name Type Target State Host ------------------------------------------------------------ TT_A...le_RAC1 application ONLINE ONLINE rac1
TT_A...le_RAC2 application ONLINE ONLINE rac2
TT_D...le_RAC1 application ONLINE ONLINE rac1
TT_D...le_RAC2 application ONLINE ONLINE rac2
ora.rac1.gsd application ONLINE ONLINE rac1 ora.rac1.ons application ONLINE ONLINE rac1 ora.rac1.vip application ONLINE ONLINE rac1 ora.rac2.gsd application ONLINE ONLINE rac2 ora.rac2.ons application ONLINE ONLINE rac2 ora.rac2.vip application ONLINE ONLINE rac2 [oracle@rac1 ~]$
[oracle@rac1 ~]$ crs_stat
… NAME=TT_Agent_tt1_oracle_RAC1 TYPE=application TARGET=ONLINE STATE=ONLINE on rac1 NAME=TT_Agent_tt1_oracle_RAC2 TYPE=application TARGET=ONLINE STATE=ONLINE on rac2 NAME=TT_Daemon_tt1_oracle_RAC1 TYPE=application TARGET=ONLINE STATE=ONLINE on rac1 NAME=TT_Daemon_tt1_oracle_RAC2 TYPE=application TARGET=ONLINE STATE=ONLINE on rac2 …
Также видим новые процессы на обоих узлах.
[oracle@rac2 ~]$ ps -ef | grep ttCRS
oracle 5007 1 0 13:18 ? 00:00:00 /u01/app/oracle/product/11.2.1/TimesTen/tt1/bin/ttCRSdaemonCmd start oracle 5008 1 0 13:18 ? 00:00:00 /u01/app/oracle/product/11.2.1/TimesTen/tt1/bin/ttCRSAgentCmd start
Теперь создадим Active-Standby pair репликацию. Данную репликацию можно создать двумя способами: используя команду create active standby pair replication или с помощью ttCWAdmin, но не обоими одновременно! В данном случае создавать и управлять репликацией будем с помощью ttCWAdmin. При запросе имени пользователя с привилегией ADMIN вводим имя adm (создан на этапе создания базы данных и объектов). [root@rac1 bin]$ ./ttCWAdmin -create -dsn ha_ds
Successful connection with Oracle clusterware stack replication DDL = create active standby pair "HA_DS" on "rac1","HA_DS" on "rac2" Enter internal UID with ADMIN privileges: adm Enter password for the same UID: Enter any phrase for password encryption: Uid/Pwd verified on host rac1 Create active standby pair scheme on this host? (Y/N)Y Waiting for confirmation from hosts... Active Standby pair created on host rac1 ================================================================== Warning!! Data store on host(s) rac2 may be destroyed in order to be duplicated from active after the roll out. Please back up this data store manually if necessary, before executing ttCWAdmin -start Command ================================================================== Registering TimesTen Cluster with Oracle Clusterware ================================================================== Number of unregistered dsn resources = 2 Registering dsn resources:... Registration complete. ================================================================== ================================================================== Number of unregistered service resources = 2 Registering service resources:... Registration complete. ================================================================== [root@rac1 bin]$
После этого в CRS появятся еще четыре сервиса, связанные непосредственно с репликацией HA_DS. Также можно заметить, что два из них не запущены - имеют статусы OFFLINE.
[oracle@rac1 info]$ crs_stat -t
Name Type Target State Host ------------------------------------------------------------ TT_A...e_HA_DS application ONLINE ONLINE rac1
TT_A...le_RAC1 application ONLINE ONLINE rac1 TT_A...le_RAC2 application ONLINE ONLINE rac2 TT_D...le_RAC1 application ONLINE ONLINE rac1 TT_D...le_RAC2 application ONLINE ONLINE rac2 TT_M...HA_DS_0 application OFFLINE OFFLINE
TT_M...HA_DS_1 application OFFLINE OFFLINE
TT_S...e_HA_DS application ONLINE ONLINE rac1
ora.rac1.gsd application ONLINE ONLINE rac1 ora.rac1.ons application ONLINE ONLINE rac1 ora.rac1.vip application ONLINE ONLINE rac1 ora.rac2.gsd application ONLINE ONLINE rac2 ora.rac2.ons application ONLINE ONLINE rac2 ora.rac2.vip application ONLINE ONLINE rac2 [oracle@rac1 info]$
[oracle@rac1 ~]$ crs_stat
… NAME=TT_Activeservice_tt1_oracle_HA_DS TYPE=application TARGET=ONLINE STATE=ONLINE on rac1 NAME=TT_Master_tt1_oracle_HA_DS_0 TYPE=application TARGET=OFFLINE STATE=OFFLINE NAME=TT_Master_tt1_oracle_HA_DS_1 TYPE=application TARGET=OFFLINE STATE=OFFLINE NAME=TT_Subservice_tt1_oracle_HA_DS TYPE=application TARGET=ONLINE STATE=ONLINE on rac1 …
Также после этого в директории, прописанной в файле конфигурации репликации (cluster.oracle.ini), появится ряд CRS-файлов (start, stop, check) для определенной репликации. [oracle@rac2 crs_scripts]$ ls
... ora_tt_tt1_HA_DS_master_1.sh ora_tt_tt1_HA_DS_master_0.sh ora_tt_tt1_HA_DS_activeservice.sh ora_tt_tt1_HA_DS_subservice.sh
Теперь посмотрим состояние репликации. [root@rac1 bin]# ./ttCWAdmin -status
TimesTen Cluster status report as of Wed Apr 14 17:00:19 2010
==================================================================== TimesTen daemon monitors: Host:RAC1 Status: online Host:RAC2 Status: online
==================================================================== ==================================================================== TimesTen Cluster agents Host:RAC1 Status: online Host:RAC2 Status: online
====================================================================
Status of Cluster related to DSN HA_DS: ==================================================================== 1. Status of Cluster monitoring components: Monitor Process for Master Datastore 1 on Host RAC1: NOT RUNNING Monitor Process for Master Datastore 2 on Host RAC2: NOT RUNNING Monitor Process for Active datastore:RUNNING on Host rac1 Monitor Process for Standby datastore:RUNNING on Host rac1
2.Status of Datastores comprising the cluster Master Datastore 1: Host:RAC1 Status:AVAILABLE State:ACTIVE Master Datastore 2: Host:RAC2 Status:UNAVAILABLE State:UNKNOWN ==================================================================== The cluster containing the replicated DSN is offline
Видим, что агенты кластера Oracle TimesTen запущены, репликация существует, но она не запущена. Теперь запустим нашу репликацию. [root@rac1 bin]$ ./ttCWAdmin -start -dsn ha_ds
Successful connection with Oracle clusterware stack Starting Cluster resources with Oracle clusterware TimesTen Cluster is starting [root@rac1 bin]$
Проверим статус репликации. [root@rac1 bin]$ ./ttCWAdmin –status
TimesTen Cluster status report as of Sat Feb 27 14:49:00 2010 ================================================================== TimesTen daemon monitors: Host:RAC1 Status: online Host:RAC2 Status: online
================================================================== ================================================================== TimesTen Cluster agents Host:RAC1 Status: online Host:RAC2 Status: online
================================================================== Status of Cluster related to DSN HA_DS: ================================================================== 1. Status of Cluster monitoring components: Monitor Process for Master Datastore 1 on Host rac1: RUNNING Monitor Process for Master Datastore 2 on Host rac2: RUNNING Monitor Process for Active datastore:RUNNING on Host rac1 Monitor Process for Standby datastore:RUNNING on Host rac2
2. Status of Datastores comprising the cluster Master Datastore 1: Host:rac1 Status:AVAILABLE State:ACTIVE Master Datastore 2: Host:rac2 Status:AVAILABLE State:STANDBY ================================================================== The cluster containing the replicated DSN is online
Видно, что реплицируемая база данных находится в состоянии online. Узлы находятся в состояниях Active и Standby. Проверим CRS. [oracle@rac1 info]# crs_stat -t
Name Type Target State Host ------------------------------------------------------------ TT_A...e_HA_DS application ONLINE ONLINE rac1 TT_A...le_RAC1 application ONLINE ONLINE rac1 TT_A...le_RAC2 application ONLINE ONLINE rac2 TT_D...le_RAC1 application ONLINE ONLINE rac1 TT_D...le_RAC2 application ONLINE ONLINE rac2 TT_M...HA_DS_0 application ONLINE ONLINE rac1 TT_M...HA_DS_1 application ONLINE ONLINE rac2 TT_S...e_HA_DS application ONLINE ONLINE rac1 ora.rac1.gsd application ONLINE ONLINE rac1 ora.rac1.ons application ONLINE ONLINE rac1 ora.rac1.vip application ONLINE ONLINE rac1 ora.rac2.gsd application ONLINE ONLINE rac2 ora.rac2.ons application ONLINE ONLINE rac2 ora.rac2.vip application ONLINE ONLINE rac2
Видно, что все сервисы находятся в рабочем состоянии. На этом конфигурация Active-Standby pair репликации завершена.
Литература
Oracle® TimesTen In-Memory Database Documentation Media Library 11g (11.2.1) Using Openfiler iSCSI with an Oracle RAC database on Linux (Doc ID 371434.1)
Проверка работы конфигурации
Посмотрим на текущее состояние конфигурации. [root@rac1 bin]# ./ttCWAdmin -status
TimesTen Cluster status report as of Fri Sep 3 15:54:23 2010 ==================================================================== TimesTen daemon monitors: Host:RAC1 Status: online Host:RAC2 Status: online ==================================================================== ==================================================================== TimesTen Cluster agents Host:RAC1 Status: online Host:RAC2 Status: online ==================================================================== Status of Cluster related to DSN HA_DS: ==================================================================== 1. Status of Cluster monitoring components: Monitor Process for Master Datastore 1 on Host rac1: RUNNING Monitor Process for Master Datastore 2 on Host rac2: RUNNING Monitor Process for Active datastore:RUNNING on Host rac1 Monitor Process for Standby datastore:NOT RUNNING 2.Status of Datastores comprising the cluster Master Datastore 1: Host:rac1 Status:AVAILABLE State:ACTIVE Master Datastore 2: Host:rac2 Status:AVAILABLE State:STANDBY ==================================================================== The cluster containing the replicated DSN is offline
Подсоединимся к узлу, имеющему состояние active, и вставим ряд записей в таблицу plans.
[oracle@rac1 ~]$ ttisql "DSN=ha_ds;UID=app;PWD=app"
Copyright (c) 1996-2009, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=ha_ds;UID=app;PWD=app"; Connection successful: DSN=ha_ds;UID=app;DataStore=/u01/app/oracle/datastore/ha_ds;DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;DRIVER=/u01/app/oracle/product/11.2.1/TimesTen/tt1/lib/libtten.so;PermSize=40;TempSize=32;TypeMode=0; (Default setting AutoCommit=1) Command> call ttRepStateGet();
< ACTIVE >
1 row found. Command> select count(*) from plans;
< 0 > 1 row found. Command> declare
> i number :=1 ;
> begin
> for i in 1 .. 1000 loop
> insert into plans (ID, NAME, PRICEPERMIN, STATUS)
> values (i, 'test', 1, 'ACT');
> end loop;
> end;
> / PL/SQL procedure successfully completed. Command> select count(*) from plans; < 1000 > 1 row found. Command>
Теперь посмотрим состояние базы данных на узле rac2. [oracle@rac2 ~]$ ttisql "DSN=ha_ds;UID=app;PWD=app"
Copyright (c) 1996-2009, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=ha_ds;UID=app;PWD=app"; Connection successful: DSN=ha_ds;UID=app;DataStore=/u01/app/oracle/datastore/ha_ds;DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;DRIVER=/u01/app/oracle/product/11.2.1/TimesTen/tt1/lib/libtten.so;PermSize=40;TempSize=32;TypeMode=0; (Default setting AutoCommit=1) Command> call ttRepStateGet();
< STANDBY >
1 row found. Command> select count(*) from plans;
< 1000 > 1 row found. Command>
Видим, что узел, находящийся в состоянии Standby, принимает информацию с узла rac1 и также доступен на чтение. Попытаемся вставить строки в таблицу plans на данном узле. Command> insert into plans (ID, NAME, PRICEPERMIN, STATUS)
> values (0, 'test', 2, 'ACT');
16265: This store is currently the STANDBY. Change to APP.PLANS not permitted. The command failed. Command>
При попытке изменения данных получаем ошибку 16265.
Теперь воспроизведем ситуацию выхода из строя одного из серверов. Для этого выполним на узле rac1 команду reboot
![root@rac1 ~]# reboot
Посмотрим состояние репликации на узле rac2.
[root@rac2 ~]# cd /u01/app/oracle/product/11.2.1/TimesTen/tt1/bin
[root@rac2 bin]# ./ttCWAdmin -status
TimesTen Cluster status report as of Tue Sep 14 20:25:12 2010 ==================================================================== TimesTen daemon monitors: Host:RAC1 Status: unavailable Host:RAC2 Status: online ==================================================================== ==================================================================== TimesTen Cluster agents Host:RAC1 Status: unavailable Host:RAC2 Status: online ==================================================================== Status of Cluster related to DSN HA_DS: ==================================================================== 1. Status of Cluster monitoring components: Monitor Process for Master Datastore 1 on Host RAC1: NOT RUNNING (ttCWAdmin) crsctl.c(21567): TT48004: clssgspubdata failed with status = 12. Monitor Process for Master Datastore 2 on Host rac2: RUNNING Monitor Process for Active datastore:RUNNING on Host rac2 Monitor Process for Standby datastore:RUNNING on Host rac2 2.Status of Datastores comprising the cluster Master Datastore 1: Host:RAC1 Status:UNAVAILABLE State:UNKNOWN Master Datastore 2: Host:rac2 Status:AVAILABLE State:ACTIVE ==================================================================== The cluster containing the replicated DSN is offline
Следовательно, Oracle Clusterware перевело узел rac2 из состояния «Standby» в состояние «Active», и пользователи могут продолжить работу на узле rac2. Также можно заметить, что узел rac1 не доступен, так как он перезагружается. После завершения данного процесса, ситуация принимает следующий вид.
[root@rac2 bin]# ./ttCWAdmin -status
TimesTen Cluster status report as of Tue Sep 14 20:49:16 2010 ==================================================================== TimesTen daemon monitors: Host:RAC1 Status: online Host:RAC2 Status: online ==================================================================== ==================================================================== TimesTen Cluster agents Host:RAC1 Status: online Host:RAC2 Status: online ==================================================================== Status of Cluster related to DSN HA_DS: ==================================================================== 1. Status of Cluster monitoring components: Monitor Process for Master Datastore 1 on Host rac1: RUNNING Monitor Process for Master Datastore 2 on Host rac2: RUNNING Monitor Process for Active datastore:RUNNING on Host rac2 Monitor Process for Standby datastore:RUNNING on Host rac1 2.Status of Datastores comprising the cluster Master Datastore 1: Host:rac1 Status:AVAILABLE State:STANDBY Master Datastore 2: Host:rac2 Status:AVAILABLE State:ACTIVE ==================================================================== The cluster containing the replicated DSN is online
Кроме этого, можно делать переключения ролей между узлами.
[root@rac2 bin]# ./ttCWAdmin -switch -dsn ha_ds
Successful connection with crs clusterware stack Swithing Active/Standby roles for the scheme of DSN HA_DS Current active host rac2 Current standby host rac1 TimesTen Cluster is starting Active standby roles are switched successfully [root@rac2 bin]# ./ttCWAdmin -status
TimesTen Cluster status report as of Tue Sep 14 20:52:07 2010 ==================================================================== TimesTen daemon monitors: Host:RAC1 Status: online Host:RAC2 Status: online ==================================================================== ==================================================================== TimesTen Cluster agents Host:RAC1 Status: online Host:RAC2 Status: online ==================================================================== Status of Cluster related to DSN HA_DS: ==================================================================== 1. Status of Cluster monitoring components: Monitor Process for Master Datastore 1 on Host rac1: RUNNING Monitor Process for Master Datastore 2 on Host rac2: RUNNING Monitor Process for Active datastore:RUNNING on Host rac1 Monitor Process for Standby datastore:RUNNING on Host rac2 2.Status of Datastores comprising the cluster Master Datastore 1: Host:rac1 Status:AVAILABLE State:ACTIVE Master Datastore 2: Host:rac2 Status:AVAILABLE State:STANDBY ==================================================================== The cluster containing the replicated DSN is online
Следовательно, мы получили достаточно надежную и работающую конфигурацию с использованием Oracle TimesTen.
Создание базы данных
На данном этапе создадим базу данных, которую будем реплицировать. Для этого создадим на обоих узлах следующие директории:
/u01/app/datastore - для хранения всех баз данных Oracle TimesTen /u01/app/datastore/ha_ds – для базы данных «ha_ds», которую будем реплицировать.
[root@rac1 ~]$ mkdir /u01/app/datastore
[root@rac1 ~]$ chown oracle:oinstall /u01/app/datastore
[root@rac1 ~]$ mkdir /u01/app/datastore/ha_ds
[root@rac1 ~]$ chown oracle:oinstall /u01/app/datastore/ha_ds
Далее выбираем один из узлов кластера для создания базы данных. В данном случае - это узел rac1. Создадим сущность в файле sys.odbc.ini.
… [ha_ds]
Driver=/u01/app/oracle/product/11.2.1/TimesTen/tt1/lib/libtten.so DataStore=/u01/app/datastore/ha_ds PermSize=40 TempSize=32 PLSQL=1 DatabaseCharacterSet=AL32UTF8 …
Далее соединяемся с базой данных «ha_ds» как администратор экземпляра Oracle TimesTen (в данном примере это oracle - он устанавливал экземпляр Oracle TimesTen) и создадим в ней необходимых пользователей:
adm – администратор базы данных и репликации (для этого данному пользователю
необходима привилегия ADMIN).
app – пользователь имеющий минимальный набор привилегий, владелец объектов.
[oracle@rac1 ~]$ ttisql ha_ds
Copyright (c) 1996-2009, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=ha_ds"; Connection successful: DSN=ha_ds;UID=oracle;DataStore=/u01/app/datastore/ha_ds;DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;DRIVER=/u01/app/oracle/product/11.2.1/TimesTen/tt1/lib/libtten.so;PermSize=40;TempSize=32;TypeMode=0; (Default setting AutoCommit=1) Command> create user adm identified by adm;
User created. Command> grant ADMIN to adm;
Command> create user app identified by app;
User created. Command> grant create session, create table to app;
Command> exit; Disconnecting... Done. [oracle@rac1 ~]$
После этого соединяемся с базой данных под пользователем app и создаем таблицу plans.
[oracle@rac1 ~]$ ttisql "DSN=ha_ds;UID=app;PWD=app"
Copyright (c) 1996-2009, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=ha_ds;UID=app;PWD=app"; Connection successful: DSN=ha_ds;UID=app;DataStore=/u01/app/datastore/ha_ds;DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;DRIVER=/u01/app/oracle/product/11.2.1/TimesTen/tt1/lib/libtten.so;PermSize=40;TempSize=32;TypeMode=0; (Default setting AutoCommit=1) Command> create table plans ( Id number(12),
> Name varchar(32 char),
> PricePerMin binary_double,
> Status char(3 char),
> primary key (Id) );
Command> exit; Disconnecting... Done. [oracle@rac1 ~]$
Установка Oracle Clusterware
Вначале установим Oracle Clusterware.
На момент написания статьи, интеграция Oracle TimesTen и Oracle Clusterware возможна только на платформах Linux x86 и Linux x86-64, и только с версией Oracle Clusterware 11.1.0.7., поэтому после установки 11.1.0.6. необходимо установить патчсет 11.1.0.7.
Процессу установки Oracle Clusterware посвящено достаточно много статей. Поэтому я не буду детально описывать этот процесс, отмечу только, что все машины должны использовать Network Time Protocol (NTP) или похожую систему для устранения расхождения во времени между машинами на интервал более чем 250 миллисекунд.
Данное ограничение связано с функционированием active-standby pair репликации в Oracle TimesTen.
В данном примере я создал 2-ух узловой кластер (установлено только Oracle Clusterware) из виртуальных машин на базе Oracle VM-сервера 2.2.0 (x86 64 bit). В качестве гостевой операционной системы использовался Oracle Enterprise Linux 5.3 (x86). В качестве разделяемой системы хранения использовался Openfiler.
Характеристики кластера:
OS username / password:
root/oracle oracle/oracle
Hostname raс1:
public IP 192.168.2.131 virtual IP 192.168.2.31 private IP 10.10.10.131 IP for openfiler 172.16.2.131
Hostname rac2:
public IP 192.168.2.132 virtual IP 192.168.2.32 private IP 10.10.10.132 IP for openfiler 172.16.2.132
Openfiler:
Public IP 172.16.2.1
Oracle Clusterware:
CRS_HOME=/u01/app/oracle/product/11.1.0/crs
Убедимся, что программное обеспечение Oracle Clusterware установлено и нормально функционирует. [oracle@rac1 ~]$ crs_stat –t
Name Type Target State Host ------------------------------------------------------------ ora.rac1.gsd application ONLINE ONLINE rac1 ora.rac1.ons application ONLINE ONLINE rac1 ora.rac1.vip application ONLINE ONLINE rac1 ora.rac2.gsd application ONLINE ONLINE rac2 ora.rac2.ons application ONLINE ONLINE rac2 ora.rac2.vip application ONLINE ONLINE rac2
Также убедимся, что установлена соответствующая версия Oracle Clusterware (11.1.0.7). [oracle@rac1 ~]$ crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [11.1.0.7.0]
Установка Oracle TimesTen 11g
После установки Oracle Clusterware инсталлируем Oracle TimesTen 11.2. Его надо установить на те же машины, на которых функционирует Oracle Clusterware, в данном случае на узлах rac1 и rac2. Вначале выполним данную операцию на узле rac1.
Я инсталлирую Oracle TimesTen 11.2.1.4 (дистрибутив можно скачать с ). Перед этим я настоятельно рекомендую ознакомиться с документацией (Oracle® TimesTen In-Memory Database Installation Guide) и выполнить шаги, описанные в разделе "Installation prerequisites" (для Linux, например, необходимо сконфигурировать huge pages, shared memory и т.д.).
Установка производится пользователем oracle (в дальнейшем, этот пользователь будет администратором экземпляра Oracle TimesTen).
Сначала создадим необходимые директории:
- /etc/TimesTen - необходима для инсталляции.
- /u01/app/oracle/product/11.2.1- здесь будет размещено программное обеспечение Oracle TimesTen.
[root@rac1 ~]$ mkdir /etc/TimesTen
[root@rac1 ~]$ chown oracle:oinstall /etc/TimesTen
[root@rac1 ~]$ mkdir /u01/app/oracle/product/11.2.1
[root@rac1 ~]$ chown oracle:oinstall /u01/app/oracle/product/11.2.1
Далее разархивируем дистрибутив. [oracle@rac1 ~]$ pwd
/home/oracle [oracle@rac1 ~]$ ls
timesten112140.linux86.tar.gz [oracle@rac1 ~]$ gunzip timesten112140.linux86.tar.gz
[oracle@rac1 ~]$ tar -xf timesten112140.linux86.tar
Далее переходим в директорию linux86 и запускаем установку.
[oracle@rac1 ~]$ cd linux86
[oracle@rac1 linux86]$ ./setup.sh
NOTE: Each TimesTen installation is identified by a unique instance name.The instance name must be a non-null alphanumeric string, not longer than 255 characters.
Вначале, предлагается ввести имя экземпляра Oracle TimesTen (или согласиться с именем по умолчанию). В данном примере имя экземпляра tt1.
Please choose an instance name for this installation? [ tt1121 ] tt1
Instance name will be 'tt1'. Is this correct? [ yes ]
Далее, предлагается выбрать компоненты для установки. В данном примере я устанавливаю все компоненты ("Client/Server and Data Manager").
Of the three components:
[1] Client/Server and Data Manager [2] Data Manager Only [3] Client Only
Which would you like to install? [ 1 ]
Далее необходимо выбрать директорию для установки программного обеспечения. В данном случае пользуемся уже созданной директорией. Of the following options :
[1] /home/oracle [2] /u01/distr/linux86 [3] Specify a location [q] Quit the installation
Where would you like to install the tt1 instance of TimesTen? [ 1 ] 3
Please specify a directory to install TimesTen? [ /home/oracle ] /u01/app/oracle/product/11.2.1
Далее предлагается ввести директорию "основного демона", самого главного процесса экземпляра Oracle TimesTen, в которой будут размещаться файлы для работы с базами данных, и др. Также предлагается установить директорию для размещения журналов работы основного демона. В данном примере используются значения по умолчанию. Where would you like to create the daemon home directory? [/u01/app/oracle/product/11.2.1/TimesTen/tt1/info] The daemon logs will be located in /u01/app/oracle/product/11.2.1/TimesTen/tt1/info Would you like to specify a different location for the daemon logs? [ no ] Installing into /u01/app/oracle/product/11.2.1/TimesTen/tt1 ... Uncompressing ...
Далее, необходимо определить порт для работы основного демона. Используются значения по умолчанию. Затем всем пользователям, кроме входящих в группу oinstall ограничиваем доступ к инфраструктуре Oracle TimesTen (TimesTen data stores, TimesTen files and shared memory). Опять используются значения по умолчанию.
NOTE: If you are configuring TimesTen for use with Oracle Clusterware, the daemon port number must be the same across all TimesTen installations managed within the same Oracle Clusterware cluster.
NOTE: All installations that replicate to each other must use the same daemon port number that is set at installation time. The daemon port number can be verified by running 'ttVersion'.
The default port number is 53384.
Do you want to use the default port number for the TimesTen daemon? [ yes ] The daemon will run on the default port number (53384).
NOTE: For security, we recommend that you restrict access to the TimesTen installation to members of a single OS group. Only members of that OS group will be allowed to perform direct mode connections to TimesTen, and only members of that OS group will be allowed to perform operations that access TimesTen data stores, TimesTen files and shared memory. The OS group defaults to the primary group of the instance administrator. You can default to this group, choose another OS group or you can make this instance world-accessible. If you choose to make this instance world-accessible, all database files and shared memory are readable and writable by all users.
Restrict access to the the TimesTen installation to the group 'oinstall'? [ yes ]
Далее, предлагается активировать возможность поддержки PL/SQL. Опять соглашаемся (по умолчанию).
NOTE: Enabling PL/SQL will increase the size of some TimesTen libraries.
Would you like to enable PL/SQL for this instance? [ yes ]
Далее, если необходимо использовать функциональность Oracle TimesTen для кэширования данных из Oracle Database, то необходимо установить на этой машине Oracle Client, и установить значение переменной ORACLE_HOME для переменной TNS_ADMIN (см. ниже). В данном примере я не буду активировать данную возможность
(s=skip).
In order to use the 'In-Memory Database Cache' feature in any databases created within this installation, you must set a value for the TNS_ADMIN environment variable. It can be left blank, and a value can be supplied later using /bin/ttModInstall.
Please enter a value for TNS_ADMIN (s=skip)? [ ] s
NOTE: It appears that you are running version 4.1 of the g++ compiler. TimesTen ships with multiple sets of client libraries and server binaries : one built for compatibility with g++ 3.4.6 and one with g++ 4.1.0. The installer has created links to the 4.1.0 library in the /lib directory and to the 4.1.0 server binary in the /bin directory. If you want to use a different compiler, please modify the links to point to the desired library and server binary.
Installing server components ...
Далее, необходимо определить порт для работы серверного процесса Oracle TimesTen, который необходим для клиент-серверного соединения. В данном примере используются значения по умолчанию.
What is the TCP/IP port number that you want the TimesTen Server to listen on? [ 53385 ]
Далее, предлагается установить документацию. Опять используем значения по умолчанию.
Do you want to install QuickStart and the TimesTen Documentation? [ no ] Would you like to install the documentation (without QuickStart)? [ yes ] Where would you like to create the doc directory (s=skip)? [ /u01/app/oracle/product/11.2.1/TimesTen/tt1/doc ] The TimesTen documentation has been installed in /u01/app/oracle/product/11.2.1/TimesTen/tt1/doc. Installing client components ...
На следующем этапе установки необходимо прописать home-директорию CRS, после чего инсталлятор показывает доступные узлы для конфигурации active-standby pair репликации. Использую значения по умолчанию, следовательно, моя репликация будет работать на узлах rac1 и rac2. Would you like to use TimesTen Replication with Oracle Clusterware? [ no ] yes
Please provide the path to the Oracle Clusterware installation on this machine (s=skip)? [ ] /u01/app/oracle/product/11.1.0/crs
NOTE: The TimesTen Clusterware agent port must be the same on all nodes of the cluster. Please refer to the TimesTen documentation for additional information. Please enter a port number for the TimesTen Clusterware agent? [ 53386 ] Executing '/u01/app/oracle/product/11.1.0/crs/bin/crsctl check cluster' ... Oracle Clusterware is currently configured on the following nodes : 1. rac1 2. rac2 NOTE: By default, all of the nodes listed above will be added to the TimesTen Replication with Oracle Clusterware configuration. You can also specify your own list of nodes based on the list above. Would you like to specify a node list for TimesTen Replication with Oracle Clusterware? [ no ] NOTE: The TimesTen daemon startup/shutdown scripts have not been installed.
Run the 'setuproot' script : cd /u01/app/oracle/product/11.2.1/TimesTen/tt1/bin ./setuproot - install This will move the TimesTen startup script into its appropriate location.
The startup script is currently located here : '/u01/app/oracle/product/11.2.1/TimesTen/tt1/startup/tt_tt1'.
The 11.2.1.4 Release Notes are located here : '/u01/app/oracle/product/11.2.1/TimesTen/tt1/README.html'
Starting the daemon ... TimesTen Daemon startup OK. End of TimesTen installation.
Далее выполняем скрипты для автоматического запуска экземпляра Oracle TimesTen после перезапуска системы.
[root@rac1 ~]$ cd /u01/app/oracle/product/11.2.1/TimesTen/tt1/bin
[root@rac1 bin]$ ./setuproot –install
Would you like to install the TimesTen daemon startup scripts into /etc/init.d? [ yes ] Copying /u01/app/oracle/product/11.2.1/TimesTen/tt1/startup/tt_tt1 to /etc/init.d Successfully installed the following scripts : /etc/init.d/tt_tt1 /etc/rc.d/rc0.d/K45tt_tt1 /etc/rc.d/rc1.d/K45tt_tt1 /etc/rc.d/rc2.d/S90tt_tt1 /etc/rc.d/rc3.d/S90tt_tt1 /etc/rc.d/rc5.d/S90tt_tt1 /etc/rc.d/rc6.d/K45tt_tt1 [root@rac1 ~]$
Проверим работу экземпляра Oracle TimesTen.
[oracle@rac1 ~]$ ttstatus
TimesTen status report as of Fri Feb 19 08:54:30 2010 Daemon pid 12978 port 53384 instance tt1 TimesTen server pid 13016 started on port 53385 ------------------------------------------------------------------------ Accessible by group oinstall End of report
Ограничения: В данной установке Oracle TimesTen не конфигурирован для кэширования данных из Oracle Database (переменная TNS_ADMIN не задана). Если в дальнейшем данная функциональность понадобится, то ее можно активировать с помощью утилиты ttmodinstall.
На этом инсталляция Oracle TimesTen завершена. Повторите процедуру установки на втором узле. Для более легкого управления рекомендуется устанавливать программное обеспечение под одним пользователем и в те же директории.
Дополнение: если вы вначале установили Oracle TimesTen и после этого установили Oracle Clusterware, то для активации возможности интеграции данных продуктов необходимо воспользоваться утилитой ttmodinstall.
это реляционная СУБД, оптимизированная для
Oracle TimesTen - это реляционная СУБД, оптимизированная для работы с оперативной памятью. Она обеспечивает приложениям возможность мгновенного реагирования и очень высокую скорость обработки данных, необходимых современным предприятиям и отраслям, работающим в реальном времени (телекоммуникации, рынки ценных бумаг, системы обороны и т. п.).
В версии 11.2.1 Oracle TimesTen приобрел несколько новых возможностей (поддержка OCI, PL/SQL, и т.д.). В данной статье рассматривается возможность управления active-standby pair репликацией Oracle TimesTen 11g с помощью Oracle Clusterware.
Целью данной статьи является создание 2-х узловой Active – Standby pair репликации Oracle TimesTen из виртуальных машин на базе Oracle VM-сервера (управление репликацией будет осуществляться с помощью Oracle Clusterware).
Oracle TimesTen имел возможность создания
В версии 7.0.5, Oracle TimesTen имел возможность создания active-standby pair репликации, но всю автоматизацию процесса обработки сбоя узла нужно было писать вручную или реализовывать на уровне приложения, что, согласитесь, не очень удобно. В новой версии 11.2.1, для этого необходимо только выполнить несколько команд, что существенно облегчает жизнь разработчикам и администратором данного программного обеспечения.
Постановка задачи
Возьмем стандартный демонстрационный пример из любой поставки Oracle: таблицу сотрудников EMP в схеме пользователя SCOTT. Предположим, что организация, в которой работают сотрудники, устроена таким образом, что каждый пользователь Oracle, обратившись к этой таблице, может видеть в ней только перечень сотрудников из своего отдела, то есть SCOTT – только сотрудников отдела 20, ALLEN – отдела 30 и так далее.
Это, конечно, простая постановка задачи, но для иллюстрации идеи она годится. От нее рукой подать до такой организации данных, при которой каждый врач, обратившись к одной и той же таблице, видит только своих пациентов и до более сложных постановок.
В соответствие с известной дихотомией «правильный метод»/ «наш метод» рассмотрим два решения: одно более правильное, а другое – более эффективное.
Это старое решение, которое давно
Это старое решение, которое давно практикуется в поставках Oracle для организации удобного доступа к таблицам словаря-справочника. В самом деле, известно, что каждый пользователь Oracle, даже при наличии у него всего-навсего привилегии CREATE SESSION, имеет возможность обратиться к примеру, к таблице USER_TABLES, чтобы посмотреть список своих собственных таблиц. Каждый пользователь обращается к одной и той же таблице (USER_TABLES), но видит в ней только свои данные.
Строго говоря, в прозвучавшей только что формулировке кроется подлог: реально USER_TABLES – это выводимая таблица (view) в схеме SYS, в определении которой присутствует ссылка на имя текущего пользователя, и для которой создан одноименный публичный (PUBLIC, то есть общедоступный) синоним. От этого-то синонима, для которого не требуется уточнения имени владельца (согласно общему правилу ссылки на небольшое количество «общесистемных» объектов, не принадлежащих никакой одной схеме), и разворачивается запрос к реальным таблицам словаря-справочника при обращении конкретного пользователя Oracle к USER_TABLES.
Как эта механика оформлена, желающие могут подсмотреть в файле-сценарии $ORACLE_HOME/rdbms/admin/catalog.sql. Он запускается (автоматически, вручную ли) при заведении базы данных почти любой конфигурации (за исключением вариантов typical и наиболее типичных в версии 10, где БД заводится не прогоном команд SQL, а копированием готовых образов с установочного клмплекта дисков). Для нашего примера эта механика будет выглядеть так.
Зайдем для начала в систему от имени SYS и заведем пользователя ALLEN:
CONNECT / AS SYSDBA (в версиях 8, 7 лучше CONNECT INTERNAL)
CREATE USER ALLEN IDENTIFIED BY ALLEN;
GRANT CREATE SESSION TO ALLEN;
Тут же, заодно, выдадим право пользователю SCOTT создавать публичные синонимы, так как изначально этого права у него нет:
GRANT CREATE PUBLIC SYNONYM TO SCOTT;
Теперь войдем как SCOTT:
CONNECT scott/tiger
CREATE VIEW emps AS SELECT * FROM emp WHERE deptno = (SELECT deptno FROM emp WHERE ename = USER);
CREATE PUBLIC SYNONYM emps FOR emps;
GRANT SELECT ON emps TO allen;
А теперь проверка:
SQL> SELECT ename FROM emps;
ENAME
----------
SMITH
JONES
SCOTT
ADAMS
FORD
5 rows selected.
А вот, что увидит ALLEN:
SQL> CONNECT allen/allen
SQL> SELECT ename FROM emps;
ENAME
----------
ALLEN
WARD
MARTIN
BLAKE
TURNER
JAMES
6 rows selected.
Замечание. При создании выводимой таблицы EMPS молчаливо подразумевалось, что в EMP имя сотрудника уникально. В существующих данных это действительно так, но в описании таблицы это обстоятельство никак не обозначено, так что при обращение к EMPS при других данных мы рискуем получить ошибку. Здесь мы закрываем на это глаза, но в промышленных системах к формулировке схемы (таблиц базовых и выводимых) нужно подходить более тщательно: в нашем случае или сделать поле EMP.ENAME уникальным, или же заменить формулировку EMPS, убрав оттуда вложенный запрос и применив соединение.
в том, что оно базируется
Выше решение № 1 было названо «правильным». Почему ? Дело в том, что оно базируется на использовании выводимых таблиц, views, которые были придуманы еще в реляционной модели (приведшей к появлению SQL) как раз для целей разграничения видимости общих данных разными приложениями (у views есть и иное предназначение, для темы этой статьи несущественное). То есть оно правильно с точки зрения старой реляционной модели.
Это «правильное» решение, однако, как и многие другие «правильные решения» не всегда оказывается эффективным или удобным на практике (только не надо последним тезисом злоупотреблять !) Иногда разработчику приложения может оказаться удобным при обращении к одной и той же таблице в течение одного и того же сеанса давать возможность предъявлять разные данные. Иногда одни и те же данные таблицы желательно предъявлять группам приложений (сеансов, пользователей). Техника использования views в таких случаях может оказаться недостаточно гибка или экономна; ей приходится искать замену.
Итак, другой способ решения нашей конкретной задачи – воспользоваться системным пакетом DBMS_RLS, поставляемым в версиях Oracle Enterprise Edition.
Он более трудоемок, и о нем будет рассказано в .
Дальнейшее развитие
В пакете DBMS_RLS предусмотрены и другие возможности, следующего порядка значимости. О них можно самостоятельно справиться в документации. Например, сформированную «политику доступа» можно включать и выключать, обновлять и так далее.
Описанный способ разграничения доступа к отдельным строкам таблицы фирма Oracle называет Fine Grained Access Control (FGAC). В документации по СУБД Oracle вы можете встретить еще одно название для разграничения доступа к строкам: Label Security. В Label Security разработчики Oracle воспользовались FGAC как основой для построения логически иной модели доступа. В рамках терминологии этой статьи и предыдущей, эту последнюю модель можно назвать «решением № 3». Ей будет посвящена отдельная статья.
Формулируем правила доступа
Наша цель – разрешить разным пользователям Oracle работать (SELECT, INSERT, UPDATE, DELETE) только с сотрудниками из таблицы EMP определенных отделов.
Для этого создадим в SQL*Plus регламентирующую таблицу, которую назовем UDPERMISSIONS:
CONNECT / AS SYSDBA
CREATE TABLE udpermissions (username VARCHAR2(14), deptno NUMBER (2));
INSERT INTO udpermissions VALUES ('SCOTT', 10);
INSERT INTO udpermissions VALUES ('SCOTT', 30);
INSERT INTO udpermissions VALUES ('ADAM', 10);
(Полагаем, что пользователь SCOTT будет работать с сотрудниками 10 и 30 отделов, а пользователь ADAM – с сотрудниками только 10).
Тут же создадим предикат, формулирующий условие доступа, отталкиваясь от содержимого только что созданной таблицы UDPERMISSIONS:
CREATE OR REPLACE FUNCTION deptsallowed ( obj_schema IN VARCHAR2 ,obj_name IN VARCHAR2 ) RETURN VARCHAR2 IS BEGIN RETURN 'deptno IN (SELECT deptno FROM udpermissions ' 'WHERE username = USER)'; END; /
Замечание. У функции DEPTSALLOWED два неиспользуемых в теле параметра. Не использовали мы их для простоты, а при желании могли бы и использовать для передачи имен схемы и таблицы, задав функцией более сложную логику. С другой стороны опыт показал, что для безошибочной работы параметры должны быть объявлены.
Тут же создадим под именем EPOLICY «политику доступа» к таблице SCOTT.EMP на основе созданного только что предиката:
BEGIN DBMS_RLS.ADD_POLICY
( POLICY_NAME => 'epolicy'
,OBJECT_SCHEMA => 'scott'
,OBJECT_NAME => 'emp'
,FUNCTION_SCHEMA => 'sys'
,POLICY_FUNCTION => 'deptsallowed'
); END; /
Перечень имеющихся «политик» можно посмотреть в таблицах DBA(USER)_POLICIES.
Так как функция DEPTSALLOWED принадлежит SYSTEM, а связываться в нашем случае она будет с таблицей SCOTT.EMP, не забудем дать пользователю SCOTT право к этой функции обращаться (неявно, через созданную политику):
GRANT EXECUTE ON deptsallowed TO scott;
Использование контекста
С каждым сеансом работы пользователя в Oracle может быть связан так называемый контекст. Он представляет собой набор пар «параметр/значение», совсем как это сделано в таблице UDPERMISSIONS выше. Там, однако, в качестве «параметров» выступали имена пользователей, а в контексте это имена отвлеченных «параметров», каких захотим. Создается контекст SQL-предложением CREATE CONTEXT …, связывается с сеансом процедурой DBMS_SESSION.SET_CONTEXT, а вот узнается почему-то обращением к стандартной процедуре SYS_CONTEXT.
Связывать контекст с сеансом можно и вручную, явной выдачей команды, но хорошая практика – поручить это триггерной процедуре, срабатывающей при подключении прикладной программы к СУБД.
Oracle рекомендует пользоваться контекстом для формулирования предиката доступа, но смысл контекста представляется не совсем уж очевидным. Хотя он и дает некоторую дополнительную свободу по сравнению с регламентирующей таблицей из примера выше (нет жесткой связи с именем пользователя), ясно, что подправив одновременно и нашу регламентирующую таблицу, и предикат, мы всегда сможем реализовать точно такую же свободу. Возможно, что рациональное зерно здесь в эффективности, так как от нас не требуется создавать специальную хранимую таблицу и обращаться к ней каждый раз, и в защищенности данных. Но достигается это за счет усложнения и очередного уклонения от реляционного подхода.
Использование пакета для политики доступа
Предикат условия доступа Oracle рекомендует оформлять в виде не отдельной функции, а пакетированной. Определенный резон в этом есть. Так, у вас может иметься несколько предикатов для разных таблиц, и объединить их в специальный пакет естественно и удобно для разработки. В тот же пакет разумно включить процедуру DBMS_SESSION.SET_CONTEXT установки контекста для сеанса, так как у нее есть странноватая особенность: она не вызывается напрямую (попробуйте !), а только из состава какого-нибудь пакета.
Как «засекретить» строки в таблице (решение № 2)
Оговорюсь сразу: «таблица» в заголовке – не обязательно базовая, а может быть и выводимая, то есть view, а с версии 10 – так же и синоним таблицы. Способ, описываемый ниже, позволяет ограничить доступ к определенным строкам таблицы (базовой ли, выводимой – не важно) разным пользователям по-разному: в зависимости от условия, которое мы сами сконструируем. Способ основан на использовании системного пакета DBMS_RLS и доступен он только в Oracle, то есть для переносимости на другие СУБД это решение – не лучший вариант, хотя и не 100%-безнадежный.
Основные элементы этого специфичного Oracle-решения таковы:
Создадим на PL/SQL функцию-предикат P, задающую условие на строки таблицы TAB. С помощью подпрограммы из пакета DBMS_RLS создадим так называемую «политику доступа», связывающую таблицу TAB с этим предикатом. Начиная с этого момента всякое обращение пользователей к таблице TAB будет автоматически заменяться СУБД на SELECT * FROM tab WHERE p, словно бы TAB была выводимой таблицей с указанной формулировкой.
Теперь дело техники – придумать определение для P так, чтобы эта функция отбирала для каждого пользователя только положенные ему строки. Тут тоже есть разные решения.
Отдельно для SELECT, INSERT, UPDATE или DELETE
У процедуры DBMS_RLS.ADD_POLICY есть еще один параметр, опущеный в примере выше в виду позволительного для него умолчания. Это параметр STATEMENT_TYPES, помощью которого имеется возможность уточнить, на какие виды действий с таблицей будет распространяться конкретный предикат. Пример использования этого параметра: STATEMENT_TYPES => 'select, update, delete'.
Пример рекомендуемого способа решения задачи
С учетом сказанного можно предложить более «правильный» (с точки зрения разработчиков Oracle) способ решения проблемы разграничения доступа к строкам:
CONNECT / AS SYSDBA
CREATE OR REPLACE CONTEXT dept_permissions USING permissions_package;
CREATE OR REPLACE PACKAGE permissions_package IS PROCEDURE set_location_context(loc IN VARCHAR2);
FUNCTION deptsallowed (obj_schema IN VARCHAR2, obj_name IN VARCHAR2)
RETURN VARCHAR2;
END permissions_package;
/
CREATE OR REPLACE PACKAGE BODY permissions_package IS
PROCEDURE set_location_context(loc IN VARCHAR2) IS
BEGIN
DBMS_SESSION.SET_CONTEXT('dept_permissions', 'location', loc);
END;
FUNCTION deptsallowed (obj_schema IN VARCHAR2, obj_name IN VARCHAR2)
RETURN VARCHAR2
IS
BEGIN RETURN
'deptno in
(SELECT deptno
FROM scott.dept
WHERE loc = sys_context(''dept_permissions'', ''location''))';
END;
END permissions_package;
/
GRANT EXECUTE ON permissions_package TO scott;
EXECUTE DBMS_RLS.ADD_POLICY - ('scott','emp','epolicy','sys', - 'permissions_package.deptsallowed','select,update')
Проверка:
SQL> CONNECT scott/tiger
Connected.
SQL> EXECUTE -
> system.permissions_package.set_location_context('DALLAS')
SQL> SELECT SYS_CONTEXT('dept_permissions', 'location') FROM DUAL;
SYS_CONTEXT('DEPT_PERMISSIONS','LOCATION')
------------------------------------------
DALLAS
SQL> SELECT ename, loc FROM emp, dept WHERE emp.deptno = dept.deptno;
ENAME LOC ---------- ------------- SMITH DALLAS
JONES DALLAS
SCOTT DALLAS
ADAMS DALLAS
FORD DALLAS
5 rows selected.
Выглядит не самым простым образом, верно. Но зато возможностей при таком решении больше, чем при работе с непакетированной функцией-предикатом или же при использовании решения № 1. Так, меняя контекст сеанса мы приобретаем возможность регулировать объем выборки из одной и той же таблицы, не выполняя дополнительных подключений к БД.
Проверяем, как работает
Теперь можно посмотреть, как это работает:
SQL> CONNECT scott/tiger
Connected.
SQL> SELECT ename, loc FROM emp, dept WHERE emp.deptno = dept.deptno;
ENAME LOC ---------- ------------- CLARK NEW YORK
KING NEW YORK
MILLER NEW YORK
ALLEN CHICAGO
WARD CHICAGO
MARTIN CHICAGO
BLAKE CHICAGO
TURNER CHICAGO
JAMES CHICAGO
9 rows selected.
Действительно, мы видим сотрудников только двух отделов.
Если у вас получились ошибки в последнем предложении SELECT, причину можно уточнить в трассировочном файле в каталоге udump (обычно это $ORACLE_HOME/admin//udump).
В качестве упражнения создайте пользователя ADAM, дайте ему права на выборку из SCOTT.EMP и убедитесь, что политика доступа работает и для него.
Развитие темы
Выше изложена суть организации «политики доступа» к строкам таблицы в ее очень простом исполнении. Однако разработчики Oracle предлагают и целый ряд дополнительных возможностей, призваных, по их мнению, сделать аппарат «политики» более востребованным. Насколько им удалось этого достичь – судите сами.
Будущее
Возможности бесконечны- например, один из файлов определения средств называется oraclec.fdf и позволяет отслеживать действия в буферном кэше. После трассировки этих действий можно, с точностью до микросекунды, определить, какие блоки были загружены в кэш, в каком порядке, и какие блоки пришлось вытеснить из кэша, чтобы можно было их загрузить. (Я подозреваю, что дополнительные расходы далеко не всегда позволят использовать этот метод.)
Еще одна возможность трассировки, которая многим пригодиться, представлена файлом connect.fdf. Он перехватывает подключения и отключения сеансов, во многом аналогично тому, как работает команда audit session. Однако в трассировочном файле накапливается еще полдюжины дополнительных статистических показателей (таких как записи повторного выполнения), которые в таблицу aud$ не попадают; и в процессе накопления запись в базу данных не выполняется.
Можно добраться и до отдельного пользователя: можно нацелить oracle_trace на трассировку действий одного пользователя. Можно даже написать SQL-оператор, читающий результирующие таблицы и генерирующий файл, аналогичный создаваемому sql_trace. При этом можно будет также отслеживать момент регистрации, перехода с одного разделяемого сервера на другой и, наконец, выхода.
Что такое oracle_trace?
oracle_trace - это компонент сервера, собирающий информацию о событиях, используя сравнительно небольшие ресурсы.
Среди этих событий - ожидания, подключения, отключения, анализ и выполнение запросов, выборка строк, и некоторые другие.
Можно собирать информацию для всего экземпляра или только для определенных пользователей, событий или процессов; причем трассировку можно включать и отключать в любой момент.
Но одна из наиболее впечатляющих возможностей oracle_trace состоит в том, что можно организовать буферизацию собранной информации и сброс ее на диск большими блоками, вместо построчной выдачи. Более того, можно потребовать, чтобы файл с собранной инфрмацией был фиксированного размера и использовался повторно.
Есчтественно, сгенерировав файл с информацией, необходимо ее анализировать. Это можно сделать двумя способами - запустить программу, строящую по данным файла ряд текстовых отчетов, или запустить программу, читающую данные файла и сбрасывающую их в набор таблиц Oracle, по которым можно будет строить собственные отчеты.
Использование средств oracle_trace
Ну, и как oracle_trace поможет ответить на исходный вопрос?
Просто: один из классов событий, которые можно трассировать, - ожидания. Надо проверить, что сервер запущен в режиме, позволяющем включить трассировку, а затем потребовать от него (либо с помощью PL/SQL, либо из командной строки) начать трассировать ожидания (waits). При этом мы ограничиваем набор событий одижания только событием 92 (это buffer busy waits в Oracle 9i, но проверьте, на всякийц случай, значения столбцов event# и name из представления v$event_name в вашей системе). Затем остается сидеть и ждать примерно час в период, когда проблема ощущается острее всего. Когда получим достаточно большой файл трассировки, прекращаем трассировку, помещаем данные из файла трассировки в базу и выполняем SQL-оператор, запрашивающий, скажем, следующее:
Для каких объектов возникали события buffer busy waits, сколько приходилось ждать, как часто возникали ожидания и кто более всего пострадал?
Если смириться с дополнительными затратами ресурсов, можно при трассировке собирать даже ожидающие SQL-операторы, что позволит узнать, какие SQL-операторы больше всего пострадали от ожиданий.
Как... ?
Как найти объект, являющийся источником всех событий buffer busy waits, которые можно увидеть в представлении v$waitstat?
Все мы читали руководства по настройке производительности: "Если вы видите ... может потребоваться увеличить количество списков свободных мест (freelists) для проблемной таблицы". Но там не сказано, как найти эту самую проблемную таблицу.
Вариант 1: выполнять непрерывный поток запросов к представлению v$session_wait и проверять значения столбцов p1, p2, p3 при возникновении этого события. Статистически, рано или поздно вы получите таким образом обоснованное представление о том, какой объект или объекты являются причиной проблемы. Этот вариант - достаточно болезненный, и результат его отчасти зависит от везения.
Вариант 2: включить событие 10046 на уровне 8 и получить поток информации об ожиданиях в трассировочных файлах. Весьма серьезно нагружает систему и тоже требует некоторого везения.
Вариант 3: есть событие (10240), которое должно порождать в трассировочном файле список адресов блоков, которые мы ожидаем (ура!), но мне еще не удавалось заставить это событие работать. Если вы знаете, как это сделать, сообщите мне, поскольку данное решение, безусловно, является оптимальным.
Итак, не хотите ли вы получить список именно тех блоков, которых приходится ждать, с идентфикаторами ожидающих сеансов, причиной и продолжительностью ожидания, и все это- с минимальными затратами ресурсов? Именно это, помимо прочего, и позволяет получить oracle_trace.
Некоторые результаты
Итак, что же мы сделали:
Создали файл конфигурации Начали сбор данных
Выполнили определенные действия в базе данных
Остановили сбор данных
Сформатировали набор данных
И что теперь?
Предположим, мы использовали файл конфигурации, представленный на рис. 2. Подключившись от имени учетной записи otrace, мы обнаружим строки в таблицах connection, disconnect и wait. Строки в таблице wait расскажут на все о событиях buffer busy waits, произошедших за время трассировки.
Например, мы могли выполнить SQL-оператор, представленный на рис. 4:
| select p1 file_id, p2 block_id, p3 reason_code, count(*) ct, sum(time_waited)/100 secs
from wait group by p1, p2, p3 order by sum(time_waited) desc ; |
Рисунок 4: Пример запроса, позволяющий выявить наиболее продолжительные ожидания занятых блоков
Если необходимо большая точность, можно выдать все ожидания с временными отметками, и столбцом, (довольно оптимистично) названным timestamp_nano.
Если необходимо выяснить, каким пользователям пришлось ждать дольше всего, измените запрос, и суммируйте по столбцам session_index (SID) и session_serial (serial#). Для получения по значениям (session_index, session_serial) имени пользователя, имени машины, времени регистрации и т.п. можно использовать таблицу (синоним) connection.
Конечно, ничего (кроме снижения производительности) не мешает соединять эту таблицу с представлением dba_extents для преобразования идентификаторов файла и блока в типы и имена объектов.
А если необходимо выявить конкретные SQL-операторы, при выполнении которых пришлось ждать, всегда, хотя и ценой затраты еще больших ресурсов, можно перейти на использование файла sql_waits.fdf, который приводит к заполнению трассировочной информацией еще нескольких таблиц, которые затем можно соединять по столбцам session_index, session_serial, timestamp и timestamp_nano.
Наконец, если вы думаете, что затраты на загрузку данных в таблицы и построение отчетов отрицательно скажутся на системе, всегда можно перенести файлы cdf и dat на другую машину и обрабатывать их в другой базе данных. Мне удалось даже, с небольшими исправлениями, сгенерировать набор данных на экземпляре версии 9i, а затем обработать их на экземпляре версии 8i, просто чтобы доказать эту возможность. Это, конечно, затруднит возможность по номерам блоков определять объекты.
Oracle_trace - лучшее встроенное средство диагностики?
Джонатан Льюис,
Перевод
В сервер Oracle встроено множество диагностического кода. Часть его, например, sql_trace, хорошо описана в документации, а часть, например, представление x$trace, не документирована вовсе. Я люблю периодически посвящать некоторое время повторному анализу такого кода, чтобы узнать, насколько расширены его возможности, получили ли они официальное признание и описаны ли в документации. Недавно, работая с сервером Oracle 9i, я с удивлением обнаружил существенное расширение возможностей oracle_trace, которое произошло за последних пару релизов. Эта статья представляет собой краткое введение в oracle_trace и описание его возомжностей.
Проблема
Есть много отличий, обычно связанных только с именами, между реализациями oracle_trace в версиях Oracle 8i и Oracle 9i. Эта статья написана исключительно на базе Oracle 9i.
Собираем все вместе
Сначала надо установить ряд параметров инициализации, чтобы на сервере можно было включить трассировку, но не включать ее сразу. Список этих параметров представлен на рис. 1.
| Обязательные oracle_trace_enable = true oracle_trace_collection_name = **
Стандартные значения oracle_trace_collection_size = 5242880 oracle_trace_collection_path = |
Рисунок 1: Параметры инициализации, связанные с oracle_trace
Параметру oracle_trace_collection_name нужно явно задать пустое значение "", ибо его стандартное значение - "oracle", а если имя набора указано и трассировка включена, сервер Oracle выполняет трассироку на уровне экземпляра с момента запуска (ого!).
Параметр oracle_trace_collection_path задает каталог, в котором будут размещаться файлы. В каталоге oracle_trace_facility_path размещаются списки событий, которые можно трассировать (facility definition files - файлы определения средств, предоставляемые Oracle Corporation). Параметр oracle_trace_facility_name задает список событий, которые нас интересуют. Наконец, можно ограничить размер (в байтах) файла с трассировочной информацией, задав значение параметра oracle_trace_collection_size.
После запуска сервера можно начинать сбор трассировочной информации.
В этой статье я буду использовать только средства командной строки, хотя есть и альтернативный PL/SQL-интерфейс (пакет dbms_oracle_trace_agent - прим. переводчика), и даже графический интерфейс, если купить соответствующий модуль для Oracle Enterprise Manager. Мы будем использовать команду следующего вида:
otrccol start 1 otrace.cfg
Команда otrccol - основной интерфейс для oracle_trace. Есть и другие команды, но большинство их возможностей были добавлены в otrccol. Очевидно, что параметр start требует начать трассировку (а параметр stop - ее остановить). Значение "1" - произвольно выбранный идентификатор задания, а otrace.cfg - файл конфигурации. Пример файла конфигурации представлен на рис. 2.
|
Используется для сбора данных col_name = jpl cdf_file = jpl dat_file = jpl fdf_file = waits.fdf max_cdf = -10485760 buffer_size = 1048576 regid = 1 192216243 7 92 5 d901 Используется для форматирования username = otrace password = otrace service = d901 full_format = 1 |
Этот файл требует от сервера создать файл с набором данных по имени jpl.dat, с файлом определения набора (collection definition file) по имени jpl.cdf и идентификатором набора jpl. Определение трассируемых средств находится в файле waits.fdf (этот файле предоставляется корпорацией Oracle и содержит только события ожидания). Размер файла трассировки будет ограничен 10 Мбайтами, но он будет использоваться повторно, так что, всегда будет содержать 10 Мбайт последних данных. Перед сбросом данных в этот файл сервер Oracle будет накапливать их в буфере размером 1 Мбайт.
Возможность задать regid - одна из наиболее мощных возможностей oracle_trace. "Стандартное" значение этой строки содержит '0 0' вместо моих '7 92', и треубет, чтобы oracle_trace трассировал весь экземпляр Oracle, который задается идентификатором d901 в конце строки. Я же попросил трассировать только средство номер 7 (события ожидания) элемент 92 (ожидания buffer busy waits).
При необходимости можно указывать в файле несколько строк regid. Для первого набора экспериментов я использовал две строки regid в файле конфигурации, задающие трассировку '7 129' и '7 130' - последовательные (sequential) и выборочные (scattered) чтения, соответственно, поскольку эти типы ожиданий легко сгенерировать.
Раздел, задающий особенности форматирования, я прокомментирую далее.
После того, как система поработает некоторое время, выполним:
otrccol stop 1 otrace.cfg otrccol format otrace.cfg
Первая команда останавливает трассировку, вторая - читает файл и сбрасывает данные в ряд таблиц Oracle.
Однако прежде чем вы сможете сформатировать набор, надо создать схему, в которой будут находиться таблицы, используемые при форматировании. В качестве имени и пароля пользователя мы используем значения, представленные ранее на рис. 2. Строка full_format=1
в файле конфигурации приводит к тому, что в таблицы будет сброшен весь файл; установка full_format=0 приведет к сбросу только новых данных. Обратите внимание также на имя службы (service) - оно задает базу данных, в которой находится соответствующая учетная запись. Чтобы использовать команду format, надо запустить процесс прослушивания TNS (TNS listener), даже если данные сбрасываются в локальную базу.
На рис. 3 представлен небольшой сценарий, создающий учетную запись и предоставляющий ей необходимые привилегии.
|
create user otrace identified by otrace default tablespace users -- если не используется 9i: -- temporary tablespace temp quota 100m on users; grant create session to otrace; grant create table to otrace; grant create sequence to otrace; grant create synonym to otrace; |
При указании опции format программа автоматически (по крайней мере, в новых версиях Oracle) создаст необходимые таблицы в указанной схеме. Часть этих таблиц бцдет иметь вполне осмысленные имена, например:
EPC_COLLECTION
Имена других будут лишены всякого смысла:
V_192216243_F_5_E_9_9_0
Проблему с неудобными именами можно решить, запусив сценарий otrcsyn.sql в каталоге $ORACLE_HOME/otrace/demo.
Этот сценарий создает синонимы для таблиц, давая им осмысленные имена, например:
WAIT CONNECTION
(Имена отличаются в разных версиях Oracle.)
Я обнаружил небольшую проблему с автоматической генерацией таблиц. Если указать один из очень избирательных списков средств (например, waits.fdf), создаются только таблицы, необходимые для представления соответствующих результатов при форматировании. Если затем вы решите использовать более полный список трассируемых средств (например, oracle.fdf) при форматировании произойдет сбой, поскольку часть таблиц есть, а других - нет. Так что, может иметь смысл поработать несколько секунд, трассируя oracle.fdf, сформатировать данные, а затем выбросить (truncate) данные из всех таблиц. Это грубый, но эффективный метод настройки соответствующей схемы.
Ссылки
--
Эта статья первоначально была опубликована на сайте , сетевом портале, посвященном проблемам различных СУБД и их решениям.
Джонатан Льюис () - независимый консультант с более чем 15-летним опытом работы с СУБД Oracle. Он специализируется на физическом проектировании баз данных и стратегиях использования возможностей СУБД Oracle, является автором книги "Practical Oracle 8I - Designing Efficient Databases", опубликованной издательсвом Addison-Wesley, а также одним из наиболее широко известных лекторов по Oracle в Великобритании. Подробнее об опубликованных им статьях, презентациях и семинарах можно узнать на сайте , где также поддерживается список ЧаВО The Co-operative Oracle Users' FAQ
по дискуссионным группам Usenet, связанным с СУБД Oracle.
Это всего лишь краткое введение
Это всего лишь краткое введение в oracle_trace, затронувшее основы его использования. Надо еще поработать над оценкой стабильности работы и побочных эффектов использования oracle_trace, не говоря уже про влияние на производительность.
Однако даже минимальное исследование показывает, что это средство требует значительно меньших расходов ресурсов, чем другие встроенные средства диагностики, обеспечивая большую гибкость и точность при построении отчетов.
В конечном итоге, oracle_trace позволяет получать точные ответы на ряд сложных вопросов, беспокоящих АБД многие годы.
Лично я не сильно удивлюсь, если oracle_trace в ближаших пару лет, в конечном итоге, заменит все остальные средства диагностики.
Целостность ссылок
Вот тут, вероятно, и наступает решающий момент для систем оперативной обработки транзакций (ООТ - OLTP). Их ждет двойной удар - сначала в подчиненной таблице, а потом и в главной.
Возьмите таблицу из и вставьте в нее еще 9 одинаковых строк, чтобы всего их стало 10. Затем выполните следующие тесты и проверьте объем логического ввода/вывода и т.п.:
update t2 set id_gp = id_gp;
10 rows updated.
alter table t1 add constraint t1_pk primary key (id_gp);
alter table t2 add constraint t2_fk_p1 foreign key (id_gp) references t1;
update t2 set id_gp = id_gp; 10 rows updated
Вы обнаружите, что количество прочитанных блоков db block gets (current mode gets) увеличится на 10 после добавления ограничения целостности. Почему? Потому что при каждом обновлении сервер Oracle проверяет ограничение внешнего ключа, и делает это путем просмотра индекса по первичному ключу в главной таблице с помощью current mode gets. Если главная таблица будет достаточно большой, может потребоваться три current mode gets для каждого избыточного обновления столбца в подчиненной таблице.
Теперь перейдем к проблемам главной таблицы. Достаточно только попытаться выполнить обновление "без изменения" строки главной таблицы, если нет индекса по внешнему ключу, и вы обнаружите печально известную блокировку TM/4. Индексы по внешним ключам не обязательны, если значения первичного ключа не изменяются и не удаляются, но если вы сталкиваетесь со случайными "зависаниями" и сообщениях о взаимных блокировках, то, вероятно, вы столкнулись с классической проблемой, - вы сами первичные ключи не обновляете, а вот генератор приложений за кадром это делает.
Индексы
Некоторые эксперименты с индексами должны быть более продуманными, поскольку для оценки всех затрат может иметь смысл учитывать логический ввод/вывод, а для этого - построить достаточно большую таблицу, чтобы индекс по ней был многоуровневым. Однако для некоторых тестов достаточно будет проверять объем данных отмены и повторного выполнения, и учитывать блокировки, оставляя в стороне такой тонкий момент, как объем логического ввода/вывода.
Итак, что же происходит при выполнении обновления без фактического изменения значения для столбца, входящего в простой индекс на основе B-дерева? Ничего. Сервер Oracle определяет, что проиндексированное значение не изменилось, и даже не обращается к индексу, не говоря уже про блокирование записи. Это верно и для простых индексов на основе битовых карт.
Вы можете усомниться, а не произойдет ли что-то ужасное при переходе на индексы по функции - не будет ли вызываться функция "на всякий случай", правильно ли отслеживает сервер Oracle зависимости между функциями и используемыми в них столбцами? Ответ: все работает правильно, никаких лишних вычислений функции или проходов по индексу не будет. В качестве теста можно создать такую же таблицу, как в , а затем выполнить следующие SQL-операторы:
create or replace function my_fun ( i1 in number, i2 in number ) return number deterministic as begin dbms_output.put_line('Testing function'); return i1 + i2; end; /
create index t2_idx on t2(my_fun(id_gp,id_p));
update t2 set id_gp = id_gp where rowid = '&m_rid';
update t2 set id_gp = id_gp + 1 where rowid = '&m_rid';
Вы увидите, что функция вызывается один раз (поскольку в таблице только одна строка), при создании индекса, но она не вызывается при обновлении без изменения значения. Кстати, при выполнении второго оператора update функция будет вызываться дважды- один раз для поиска исходного местонахождения в индексе, а второй - для вычисления нового. Вы можете обнаружить, что функция вызывается еще два раза при выполнении отката - я уверен, что сталкивался с этим в прежних версиях, когда индексы по функции только появились, но сейчас это больше не происходит.
Компромисс будет всегда
Вы могли уже решить, что пора переписывать массу кода. Но, написание кода, генерирующего идеальный SQL-оператор каждый раз, повышает вероятность ошибок. Компромисс между повышенным риском ошибки (а также временем на кодирование, тестирование и отладку) и производительностью всегда будет, так что, если сервер далек до полной загрузки, вполне допустимо и обоснованно будет игнорировать все описанные выше проблемы. По крайней мере, в краткосрочной перспективе.
Есть и еще один, более тонкий компромисс. Если приложение генерирует идеальный SQL-оператор для каждого обновления, которое оно потенциально может сгенерировать конечное приложение, то существенно возрастает количество различных SQL-операторов в системе.
Теоретически, если в таблице есть N столбцов, тогда разных операторов update может быть power(2,N) - 1, и это если ограничиться только однострочными обновлениями по rowid. Если не увеличить соответственно разделяемый пул и не настроить несколько параметров, вроде session_cached_cursors, может оказаться, что экономия в одном месте оборачивается дополнительными проблемами (такими как конфликты доступа к библиотечному кэшу) в другом.
Краткая история генераторов форм
Было время, когда в SQL*Forms (так его тогда называли) было принято использовать единственный SQL-оператор обновления для блока. Этот оператор update обновлял (по значению rowid) каждый столбец таблицы, упоминающийся в блоке. Это казалось неплохой идеей, поскольку упрощало код и делало его более эффективным на клиенте: не нужно было решать вычислительно сложную задачу определения действиетльно измененных полей и динамически формировать SQL-оператор для обновления только соответствующих столбцов в базе данных.
Потом, в районе версии Forms 4.5 (я могу ошибаться с версией - жду поправок), корпорация Oracle добавила флаг, который можно устанавливать для выбора либо одного оператора, "обновляющего все", либо динамически генерируемого оператора "обновлять только минимальный набор столбцов". Какая из этих опций лучше?
Но это еще не все
Дополнительный объем данных отмены и повторного выполнения - это еще не обязательно самая большая проблема - в конечном итоге, дополнительно генерируемые и буферизуемые данные зачастую не так уж велики по сравнению с базовыми накладными расходами. Более того, поскольку архитектура сервера Oracle такова, что записи на диск, по возможности, выполняются фоновыми "асинхронными" процессами, конечный пользователь не часто ощущает замедление из-за записи на диск. Но есть еще ряд нюансов, непосредственно влияющих на производительность системы с точки зрения конечных пользователей.
Как вы думаете, что делает сервер при обновлении столбца без реального изменения со следующими объектами:
Срабатывают ли строчные триггеры типа 'update of {список_столбцов}'?
before row
after row
instead of Изменяются ли индексы, включающие такой столбец?
Что, если это индексы на основе B*-дерева?
А как насчет индексов на основе битовых карт?
Что будет с индексами по функции (function-based indexes)?
Как сервер будет обеспечивать целостность ссылок?
Если этот столбец - подчиненный?
Если этот столбец - главный?
Сколько стоит обновить столбец?
В частности, нас будет интересовать, сколько стоит обновление столбца, если его значение не меняется. Если бы сервер мог выявить, что при обновлении реально ничего не меняется, то дополнительные расходы ресурсов на лишнее обновление были бы минимальны. К сожалению, сервер и не пытается выявлять "лишние" обновления. В конечном итоге, логично предполагать, что при обновлении данные должны меняться. Было бы контрпродуктивно добавлять проверку условия, которое почти всегда будет истинным, просто чтобы немного сэкономить в тем "весьма редких и странных" случаях, когда при обновлении изменения не происходят.
Итак, что же может произойти при обновлении одного столбца в таблице в отдельной транзакции? Понятно, что строку надо заблокировать и данные изменить, а для этого - получить запись списка заинтересованных транзакций (Interested Transaction List - ITL) в блоке. Необходимо захватить слот таблицы транзакций (transaction table slot) в заголовке сегмента отмены (undo segment header) для использования в качестве глобально видимой "ссылки" на транзакцию, а также внести запись отмены в блок отмены, описывающую, как отменить изменения, только что выполненные в блоке данных. Изменения во всех трех блоках необходимо записать в журнал повторного выполнения (первоначально - в буфер журнала), и в этом простом случае потребуется только одна запись повторного выполнения (redo record).
Затем, при фиксации транзакции в слоте таблицы транзакций записывается соответствующее значение номера системного изменения (commit SCN) и он помечается как свободный, а адрес использованного блока отмены тоже можно записать в пул свободных блоков в блоке заголовка сегмента отмены. Эти изменения в блоке заголовка сегмента отмены записываются в журнал повторного выполнения (в буфер), а для сброса буфера журнала на диск вызывается процесс записи журнала (log writer process - lgwr), после чего пользовательский процесс уведомляют, что транзакция успешно зафиксирована. (Oracle может, а в этом случае, скорее всего, и будет также очищать измененный блок данных, но не будет записывать выполненные при очистке изменения в журнал повторного выполнения).
Предположим, пользователь изменил на экране всего одно поле - представленное выше описание дает понять, какой объем работы придется выполнить серверу, чтобы реализовать это изменение. Но что, если генератор форм обновил всю строку - какие дополнительные расходы ресурсов при этом возникают?
Затраты на получение записи ITL, блокирование и обновление строки, вероятно, не сильно изменятся, а затраты на получение блока заголовка сегмента отмены вообще не изменятся.
Но вот объем данных в записи отмены, вероятно, возрастет существенно - вместо дополнительных примерно 100 байт плюс старая версия одного столбца мы получим дополнительные байты плюс старая версия всех столбцов. Вероятно, это не так уж важно, - в конечном итоге, сервер Oracle пишет блоки, а не записи, - но если записи отмены в результате выросли по размеру в четыре раза, придется записывать в четыре раза больше блоков отмены.
Аналогично, существенно изменится и запись повторного выполнения. В идеале, запись повторного выполнения будет для этого изменения длиной около 200 байтов (плюс еще 200, связанных с с блоком заголовка сегмента и вектором аудита транзакции). Эта запись, вероятно, будет дополнена до 512 байтов (типичный минимальный размер блока ОС) всяким мусором при фиксации транзакции. Но основная запись повторного выполнения состоит, по сути, из двух векторов изменений - вектора для блока таблицы и вектора для записи отмены, - и оба они увеличатся в размере, потому что запись отмены будет включать старую версию всех столбцов, а запись повторного выполнения для таблицы - новую версию всех столбцов. Поэтому объем генерируемых данных повторного выполнения увеличивается в два-четыре раза, а во многих интенсивно загруженных системах скорость сброса данных повторного выполнения на диск часто является критической проблемой производительности.
Сколько стоит update?
Джонатан Льюис,
Перевод
На рынке есть несколько генераторов приложений, поддерживающих базовый подход к разработке "чем проще, тем лучше". Простой код легче генерировать и проще сопровождать, даже если он кажется несколько менее эффективным. Но если генератор форм всегда генерирует код для обновления каждого столбца в таблице, даже если пользователь меняет всего лишь одно поле в форме, насколько при этом растет нагрузка на сервер базы данных?
Триггеры
Создадим простую таблицу с триггером и выполним действия, представленные ниже в листинге 1:
Листинг 1
create table t2 ( id_gp number(4), id_p number(4), n2 number(4) ); insert into t2 values (1,1,1); commit;
create or replace trigger t2_bru before update of id_gp on t2 for each row -- when ( -- new.id_gp != old.id_gp --or new.id_gp is null and old.id_gp is not null --or old.id_gp is null and new.id_gp is not null -- ) begin dbms_output.put_line('Updating'); end; /
column rid new_value m_rid
select rowid rid from t2 where rownum = 1;
update t2 set id_gp = id_gp where rowid = '&m_rid';
Триггер срабатывает. То же самое происходит и с триггером after-row update. Подтверждение моего предположения, что сработает и триггер instead of оставляю читателю в качестве упражнения.
Фактически, строчный триггер before генерирует одну дополнительную запись отмены и одну дополнительную запись повторного выполнения, даже если ничего при этом не делает из-за добавления достаточно сложной конструкции when, которая в примере закомментирована. Так что, если есть выбор, немного эффективнее будет использовать строчные триггеры after.
Если разрешить инструментальным средствам создания
Если разрешить инструментальным средствам создания конечных приложений использовать простой способ обновления данных (путем генерации одного SQL-оператора для всех возможных обновлений), нагрузка на систему может существенно возрасти. При работе в среде клиент-сервер или в многоуровневой архитектуре может иметь смысл использовать дополнительные вычислительные ресрсы на клиенте или сервере приложений для построения специфических SQL-операторов, минимизирующих затраты ресурсов на сервере. Решение при этом, однако, - не очевидное. Убедитесь, что преимущества окупят затраты.
--
Джонатан Льюис () - независимый консультант с более чем 17-летним опытом использования Oracle. Он специализируется на физическом проектировании баз данных и стратегии использования сервера Oracle. Джонатан - автор книги "", опубликованной издательством Addison-Wesley, и один из наиболее известных лекторов среди специалистов по Oracle в Великобритании. Подробнее о его публикациях, презентациях и семинарах можно узнать на сайте , где также находится список ЧаВО The Co-operative Oracle Users' FAQ
по дискуссионным группам Usenet, связанным с СУБД Oracle.
Эта первоначально была опубликована на сайте , сетевом портале, посвященном проблемам различных СУБД и их решениям. Перевод публикуется с разрешения автора.
