Показаны сообщения с ярлыком Enterprise Manager. Показать все сообщения
Показаны сообщения с ярлыком Enterprise Manager. Показать все сообщения
Про Enterprise Manager, про его паки, про DBA и про меня
Тема требует продолжения. Меня всегда интересовало, как относятся DBA-профессионалы к использованию Enterprise Manager.
Я сам никогда не администрировал базы профессионально (под понятием профессионально я понимаю такой род деятельности, которым человек зарабатывает по крайней мере половину своих денег; в соответствии с этим определением мы, например, с Димой Волковым не являемся фотографами-профессионалами или водителями-профессионалами). Около семи-восьми лет назад я работал в компании Borlas техническим архитектором проекта внедрения OeBS. Проект только начал разворачиваться и со стороны заказчика еще не было DBA. Мне приходилось делать некоторые базовые операции, характерные для DBA. Для начала я написал select, который объединял 3-4 V$-вьюхи, чтобы посмотреть какие сейчас в базе блокировки. Потом я написал супер-крутой скрипт, чтобы убивать подвисшие сессии, по каким-то там двум id-шникам. Еще через некоторое время у меня возник уже набор различных стриптов. Я хранил их разложенными по папочкам, писал для каждого комментарии, чтобы не забыть, и каждый раз, когда встречалась какая-то уже изученная раньше ситуация, я лез в папочку со скриптами. Через пару месяцев я даже произвел на кого-то впечатление, быстро запустив скрипт из папки номер 16, который срубил пару повисших сессий. Я уже посчитал, что стал страшно крут, и уже хотел было записать в свое резюме отдельной строчкой что я DBA, пока жизнь не познакомила меня с настоящим DBA.
Через три месяца после старта проекта компания Shreya, где мы внедряли OeBS, смогла-таки позволить себе нанять профессионального DBA, который блестяще прошел мое супер-пупер-навороченное техническое интервью, в котором самыми каверзными были вопросы о максимальной длинне строки, которую без ошибки переваривает dbms_output.put_line в Oracle9i (ограничение, на которое я случайно сам налетел неделю назад) и задачка на составление select с конструкцией having. В то время только что лопнул "пузырь .com" и парень возвратился назад из США, потеряв там работу промышленного DBA. В общем, работу он получил и был включен в мою команду со стороны заказчика.
И тут я понял, насколько велика пропасть между мной и этим парнем. Какие тут скрипты? О чем Вы говорите? Этот человек мог хладнокровно разобраться, что именно надо делать, если база OeBS словила corruption. Тут скрипт и написать-то нельзя. Я тогда даже не представлял, что такое corruption и почему он может произойти. Его опыт был настолько велик, что миллион проблем, с которыми я боролся при помощи тряпки, палки и каких-то там скриптов исчезли сами собой. Это был человек другого уровня. Если бы я посвятил всю жизнь осваиванию технических аспектов работы СУБД Oracle, то после запуска нашего проекта в production, я мог бы претендовать максимум на ночные дежурства под присмотром этого парня на уровне если случилось это -- нажми на эту кнопку, а если вот это -- ничего не трогай и спрочно вызывай меня. Про строчку DBA в резюме пришлось забыть.
Да, к чему я это все рассказываю? Потому, что во время этого проекта я понял, что профессия DBA -- это очень широкий пласт опыта, плюс работа головой с тонкими вещами. Я понял, что такие "DBA" как я, не нужны рынку труда. Почему? Ответ: потому, что меня с моими скриптами можно заменить куском продвинутого программного обеспечения, а того, настоящего DBA, нельзя, потому, что есть множество операций, которые принципиально нельзя автоматизировать. Пример -- что делать с corruption? (уверен, что Дима Волков сможет продолжить этот список). В 2003 году выход Oracle 10g с его встроенной концепцией само-настраиваемости окончательно утвердил мой вывод: С Oracle 10g такие как я не нужны рынку -- вся статистика собирается специальным джобом, все работает в режиме auto, и т.п. Для того, чтобы продать себя и представлять ценность для работодателя, нужно быть по крайней мере умнее этого самого режима auto.
Теперь при чем тут Enterprise Manager с его паками? Потому, что этот продукт помогает профессиональному DBA сосредоточиться на той части своей карьеры, которая позволит повысить свою капитализацию на рынке труда (как Вы уже поняли, я обожаю писать про карьеру и меня все время сносит в эту сторону :^). Почему? Потому, что Enterprise Manager поможет DBA сосредоточиться на выработке опыта, который принципиально не может быть автоматизирован. DBA может и должен (!) делать множество технически сложных, но при этом рутинных операций в Enterprise Manager, который по сути представляет высокопараметризированную библиотеку все тех же скриптов. И наоборот, чем DBA будет меньше работать с Enterprise Manager, чем больше он будет придумывать свои скритпы, тем больше и больше он будет похож на меня :^)
Вы DBA-профессионал. Забудьте на минуту о лицензиях Oracle.
Вы используете Enterprise Manager?
(Дим, мы можем сделать на этом блоге опрос?)
P.S. А что же тот DBA? Он опять уехал в Северную Америку, но на этот раз в Канаду. Похоже, что навсегда. ...я иногда вспоминаю о нем...
Читать дальше...
Про Diagnostics Pack, Tuning Pack и их лицензирование без использования GUI Enterprise Manager
Нас часто спрашивают про лицензирование Diagnostics Pack и Tuning Pack без использования GUI Enterprise Manager. Читаем документ Oracle Database Licensing Information начиная со страницы 2-20.
В версии 11g поддержка этих двух паков контролируется на уровне СУБД параметром СONTROL_MANAGEMENT_PACK_ACCESS, который имеет одно из трех значений: NONE (ничего не включено), DIAGNOSTIC (включен только Diagnostic), DIAGNOSTIC+TUNING (включены оба). Обратите внимание, что нет четвертой комбинации "только TUNING". С точки зрения логики лицензирования заказчик не может купить Tuning не купив Diagnostics -- ну как можно что-то лечить (тюнить), пока не поставлен диагноз? Если Вы ставили Enterprise Edition, то по умочланию значение этого параметра = DIAGNOSTIC+TUNING. Поэтому, если Diagnostics Pack и Tuning Pack у Вас не лицензированы, то параметр надо вручную поставить в значние NONE :^) Все это верно только для версии 11g. В версии 10g доступ к функциональности паков отключить на уровне СУБД нельзя, что не освобождает от ответственности их лицензировать, если паки реально используются.
Теперь самое интересное. Каково определение "реально используются"? Как Вы уже знаете, паки работают на уровне СУБД, где они собственно и собирают всяческую полезную информацию. Oracle не интересует каким образом осуществляется доступ снаружи. Доступ к этой информации/функциональности может осуществляться как со стороны графического интерфейса Enterprise Manager, так и с помощью database command-line API, всяческих скриптов, программы SQL*Plus, TOAD, SQL Developer, QUEST Spotlight и множества других продвинутых и не очень вещей. С точки зрения лицензирования Ораклу все равно какое средство осуществляет доступ к информации/функциональности паков. Существует простое правило: если паки используются напрямую или опосредованно, то их надо лицензировать.
Кстати, этим правилом лицензирования Oracle убил бизнес некоторых компаний, специализирующихся на создании внешних интерфейсов к этим пакам, так как получается, что необходимо лицензировать Enterprise Edition, Diagnostics/Tuning packs и одновременно продукт третьей фирмы.
Вообще, пора делать отдельный семинар Deep Dive to Oracle Licensing :^) -- тaм навалом различных тем.
Читаем документ Oracle Database Licensing Information дальше, чтобы понять, надо ли лицензировать Diagnostics Pack, если у нас, например, есть отчет, который использует V$ACTIVE_SESSION_HISTORY...
Diagnostics Pack определяется как следующий контур функциональности:
Oracle Diagnostics Pack features can also be accessed by way of database server APIs and command-line interfaces:
- The DBMS_WORKLOAD_REPOSITORY package is part of this pack.
- The DBMS_ADDM package is part of this pack.
- The DBMS_ADVISOR package is part of this pack if you specify ADDM as the value of the advisor_name parameter, or if you specify for the value of the task_name parameter any value starting with the ADDM prefix.
- The DBMS_WORKLOAD_REPLAY.COMPARE_PERIOD_REPORT function is part of this pack.
- The V$ACTIVE_SESSION_HISTORY dynamic performance view and its underlying table, X$ASH, are part of this pack.
- The DBA_STREAMS_TP_PATH_BOTTLENECK view is part of this pack.
- All views beginning with DBA_ADDM_ are part of this pack.
- Some data in DBA_STREAMS_TP_COMPONENT_STAT requires Oracle Diagnostics Pack. The following filter clause to any query on DBA_STREAMS_TP_COMPONENT_STAT shows Diagnostics-Pack-dependent data:
where STATISTIC_UNIT = 'PERCENT'
For example, the following query shows Diagnostics-Pack-dependent data only:
SELECT * FROM DBA_STREAMS_TP_COMPONENT_STAT
where STATISTIC_UNIT = 'PERCENT';
- All data dictionary views beginning with the prefix DBA_HIST_ are part of this pack, along with their underlying tables.The only exception are the views: DBA_HIST_SNAPSHOT, DBA_HIST_DATABASE_INSTANCE, DBA_HIST_SNAP_ERROR, DBA_HIST_SEG_STAT, DBA_HIST_SEG_STAT_OBJ, and DBA_HIST_UNDOSTAT. They can be used without the Oracle Diagnostics Pack license.
- All data dictionary views with the prefix DBA_ADVISOR_ are part of this pack if queries to these views return rows with the value ADDM in the ADVISOR_NAME column or a value of ADDM* in the TASK_NAME column or the corresponding TASK_ID.
- The following reports found in the /rdbms/admin/ directory of the Oracle home directory are part of this pack: awrrpt.sql, awrrpti.sql, awrgrpt.sql, awrgrpti.sql, awrgdrpt.sql, awrgdrpi.sql, addmrpt.sql, addmrpti.sql, ashrpt.sql, ashrpti.sql, awrddrpt.sql, awrddrpi.sql, awrsqrpi.sql, awrsqrpt.sql, awrextr.sql, awrload.sql, awrinfo.sql, spawrrac.sql.
Tuning Pack определяется как следующий контур функциональности:
Oracle Tuning Pack features can also be accessed by way of database server APIs and command-line interfaces:
- DBMS_SQLTUNE
- DBMS_ADVISOR, when the value of the advisor_name parameter is either SQL
Tuning Advisor or SQL Access Advisor.
- V$SQL_MONITOR
- V$SQL_PLAN_MONITOR
- The following report found in the /rdbms/admin/ directory of the Oracle home
directory is part of this pack: sqltrpt.sql.
Читать дальше...
Основная тема 11g R2: Снижение затрат
Ну на чем еще мог сконцентрироваться Oracle, выпуская 11g R2, кроме как на теме Cost Savings?
Сейчас все только и говорят об этом. CEO не спят ночами -- ворочаются в кровати и стонут. Акции падают. CFO начинают неровно дышать, когда к ним приходят спецификации расходов на IT. CIO сами бегают по вендорам и умоляют предложить технологии, которые позволят съэкономить -- иначе их завтра уволят. IT-шники жалуются, что несправедливо срезают зарплату. Единственная тема, к которой прислушиваются -- Cost Savings. Читаем свежую whitepaper про 11g R2.
Кризис? Вы перестали летать первым классом? Тогда почему все Ваши данные должны продолжать летать первым классом? Нет, Вы объясните мне -- почему? Срочно внедряйте Partitioining. Самые востребованные данные оставляете на high end storage, а остальные идут на mid range и low end соответственно. И еще прессуйте их Advanced Compression (там и приложение быстрее заработает). Иначе Ваши данные будут прессовать Вас. Закон джунглей кризиса: "либо Ваш обед достанется Вам, либо его скушает кто-то другой". Возьмите калькулятор и подсчитайте сколько кушают Ваши данные, если Вы еще разрешаете им всем летать первым классом. Теперь подумайте о собственном обеде. ...хмм, похоже меня понесло :^) Пойду-ка я пообедаю...
P.S. Как Вы уже поняли из предыдущего сообщения про Sun, Дима Волков поедет с Вами на Open World 2009 (и полетит эконом классом :^). Когда прилетите в Sun (или Sаn как правильно?) Francisco, пошлите ему sms: +7 (9 I 6) 2 9 0 - Ч 5 - I 5.
Читать дальше...
Подписаться на:
Сообщения (Atom)
Сообщения
