Металинк oracle что это
Администрирование Oracle. Программирование на PL\SQL. А также все что касается лидера разработки корпоративного ПО.
пятница, мая 11, 2007
Creating an Account
You must have a My Oracle Support account before you can access My Oracle Support. Follow these instructions:
Click the New user? Register here link. The registration page opens.
Follow the instructions on the registration page.
Finding Patches and Documents on Classic MetaLink
Select Classic Metalink and log in.
In the Quick Find drop-down list, select either Patch Number or Document ID .
Enter the patch number or document ID.
Второй вопрос — сайзинг
Миграция Oracle Database между платформами с разным Endian-форматом значительно сложнее и связана со многими дополнительными аспектами. Например, в сообществе широко обсуждаются вопросы сайзинга. Несколько лет назад мы провели масштабное исследование производительности Oracle Database на самых распространенных рисковых платформах Power/AIX и Sparc/Solaris в сравнении с платформой x86.
Для тестирования мы выбрали нагружающие скрипты Silly Little Oracle Benchmark (SLOB), разработанные Кевином Клоссоном. В отличие от большинства генераторов синтетической нагрузки с «вшитыми» запросами, эти скрипты в несколько потоков запускают собственные запросы к базе данных. Запросы мы разработали так, чтобы избежать влияния дисковой подсистемы (все данные были в прогретом кеше) и конкуренции за внутренние ресурсы экземпляра Oracle (у каждого потока свои данные). Мы измеряли число логических чтений в секунду при растущем объеме параллельных неконкурирующих потоков SLOB. В исследовании участвовали 16-ядерные домены рисковых серверов с актуальными на момент исследования процессорами Power8 и Sparc M7 в сравнении с 16-ядерным x86 сервером Intel. На рисунке показан характерный результат, полученный при сравнении платформ (ось X — потоки SLOB, ось Y — логические чтения в секунду).
На невысоких нагрузках лучшую производительность показывает x86 сервер, в том числе за счет аппаратных возможностей процессора Intel. При росте количества сессий SLOB (после 32) происходит перелом и рисковые серверы выходят вперед — начинает работать многопоточность (в ядре процессора Intel два треда, в ядре процессоров Power8 и Sparc M7 до восьми тредов). Следует заметить, что запросы к Oracle были разработаны таким образом, чтобы утилизировать все треды — в реальных системах это бывает далеко не всегда. Именно многопоточность объясняет окончательную «победу» сервера Sparc. В процессоре Power8 режим SMT=8 (восемь тредов на ядро) работал настолько своеобразно, что даже сам вендор рекомендовал использовать режим SMT=4 (четыре треда на ядро).
Результаты сравнительного исследования оказались неоднозначными. Для себя мы сделали вывод, что получить точный сайзинг можно, только тестируя работу конкретной базы данных на новой платформе. Но для этого базу нужно мигрировать. Поэтому часто требуется предварительный сайзинг, для которого мы используем принцип «ядро в ядро», несмотря на разнообразие сравнительных синтетических тестов типа SpecInt. Этот принцип серьезно усложняет обоснование, почему нужно мигрировать на Power/AIX. Нередко приходится искать дополнительные аргументы со стороны заказчика, а то и с помощью вендора. Дело в том, что оракловый коэффициент многоядерности (Core Factor) для процессоров IBM вдвое выше. И при одинаковом количестве ядер лицензирование Oracle получается вдвое дороже:
Vendor and Processor | Core Factor |
Intel Xeon Platinum 92XX, Intel Xeon Platinum 82XX, Intel Xeon Platinum 81XX, Intel Xeon Gold 62XX, Intel Xeon Gold 61XX, Intel Xeon Gold 52XX, Intel Xeon Gold 51XX, Intel Xeon Silver 42XX, Intel Xeon Silver 41XX, Intel Xeon Bronze 32XX, Intel Xeon Bronze 31XX, Intel Xeon Series 56XX, Series 65XX, Series 75XX, Series E7-28XX, E7-28XX v2, Series E7-48XX, E7-48XX v2, E7-48XX v3, E7-48XX v4, Series E7-88XX, E7-88XX v2, E7-88XX v3, E7-88XX v4, Series E5-24XX, E5-24XX v2, E5-24XX v3, Series E5-26XX, E5-26XX v2, E5-26XX v3, E5–26XX v4, Series E5-46XX, E5-46XX v2, E5-46XX v3, E5-46XX v4, E3-15XX v5, E3-15XX v6, Series E3-12XX, E3-12XX v2, E3-12XX v3, E3-12XX v4, E3–12XX v5, E3-12XX v6, E5-14XX v3, E5-14XX v2, E5-16XX v4, E5-16XX v3, E5-16XX v2, and E5-16XX or earlier Multicore chips | 0.5 |
SPARC M5, SPARC M6, SPARC M7, SPARC M8 | 0.5 |
IBM POWER6, IBM POWER7, IBM POWER7+ | 1.0 |
IBM POWER8, POWER9 | 1.0 |
Navigating to the Oracle Clinical 4.6 Knowledge Page
Follow these instructions to open the My Oracle Support's Oracle Clinical 4.6 product page:
Select My Oracle Support (requires Flash) and log in.
The My Oracle Support portal opens, displaying general news from several categories.
Click the Knowledge tab.
Check the top of the page. If PowerView is on and a product other than Oracle Clinical 4.6 is displayed, turn PowerView off.
In the Browse any Product, By Name drop-down list, select Oracle Clinical and click the icon.
In the Refine Search region on the right, click on a topic of interest; for example, Install, Upgrade .
My Oracle Support displays a list of documents that satisfy the search criteria.
Click a document's link to view it.
Oracle CPU Security Updates
Oracle Corporation publishes a CPU Security Update patch quarterly. Install these patches on every computer with an Oracle Home. Check My Oracle Support's (MetaLink's) Oracle Clinical Knowledge page for information on the latest patch tested with Oracle Health Sciences applications.
Думаю, многим разработчикам ПО и предпринимателям буду интересны некоторые особенности лицензионной политики и технической поддержки компании Oracle.
Начать разработку своих приложений на Oracle очень просто, и денег за это Oracle не возьмет. Интересное начнётся потом, когда проект надо будет легализовать.
Order Form и стоимость стандартной технической поддержки
При каждой покупке лицензий Oracle обеими сторонами подписывается документ, называемый «Order Form», который содержит перечисление лицензий, дату начала их действия и стоимость.
За все свои продукты и техподдержку Oracle требует 100% предоплату. Исключение из этого правила могут получить только бюджетные организации, попросив это официальным письмом.
При покупке программных продуктов сразу в обязательном порядке продается и стандартная техподдержка для них сроком на 1 год.
Разумеется, по программе СТП Oracle решает только массовые проблемы. Если хотите получить внимание инженеров Oracle именно к своей конфигурации, то к стандартной ТП необходимо докупить расширенную техподдержку (менеджер Oracle прикинет, сколько часов и на что им надо будет потратить, умножит на 3,14 и т.д.). Разумеется, необходима 100% предоплата, а по окончании договора неизрасходованные средства не возвращаются и не переносятся на следующий период расширенной поддержки.
Стоимость СТП на 1-й год составляет 22% от стоимости лицензий, указанной в Order Form. Каждый последующий год стоимость СТП увеличивается на 3% от своей величины (не от стоимости лицензий, а на 3% от своего предыдущего значения).
Эту надбавку Oracle называет «inflation rate». В лицензионном соглашении [1] Oracle обещает не повышать стоимость стандартной техподдержки более чем на 4% в год (Пункт H на стр. 4).
Последствия отказа от техподдержки
От стандартной техподдержки со второго года и далее можно отказаться, и продолжать легально использовать купленные продукты, но есть два нюанса:
1. Если Вам когда-нибудь потом понадобится СТП, то перед тем, как Вы сможете купить её, Oracle потребует заплатить штраф — в 1,5 раза больше, чем стоила бы стандартная ТП за пропущенный период.
Понятно, что таким образом Oracle страхуется от вариантов «раз в 3 года купил СТП сроком на 1 год и обновил версию ПО». По-моему некоторую сумму за возобновление ТП можно требовать, но наличие повышающего коэффициента при этом совершенно выходит за границы добра. Мало того, что по сути Oracle получает выплату за неоказанную услугу (в России это незаконно), так еще и в 1,5 раза больше.
2. Свои программные продукты Oracle разделяет на «комплекты лицензий» (subset of licenses) — группы лицензий по их назначению (Database, Middleware, Applications и пр.), причем не важно, что они куплены в разное время по разным Order Form.
Например, все Купленные Вами Database Oracle отнесет к одному «комплекту лицензий», а WebLogic Server попадает уже в другую. Подробнее, какое ПО входит в какой «комплект» можно посмотреть в Oracle Software Technical Support Policies [2].
Oracle требует, чтобы у Пользователя все лицензии из одного «комплекта» находились на одном уровне стандартной техподдержки. Уровней целых два – «есть СТП» и «нет СТП».
Теперь предположим, у Вас есть давно купленный Database Standard, на котором у Вас крутится какая-то вспомогательная система, и Вам не нужна была СТП на неё. Со временем Вам потребовалось докупить на бизнес-критичную задачу Database Enterprise. Вот Вы и попали на штраф за пропущенный период СТП для DB Standard.
Oracle предлагает замечательный выход такой из ситуации – отказаться от «лишних» лицензий, по которым Вы не хотите платить штраф за пропущенный период СТП, написав так называемый Termination Letter.
Тут некоторые задумаются, нельзя ли передать ли DB Standard дружественному юрлицу перед покупкой DBE. Не углубляясь, замечу, что совместно использовать Oracle разными «своими» юрлицами тоже не просто, например, нельзя пускать пользователей из другого юрлица в DB, если она лицензирована по NUP, а не по CPU.
Особенности политики скидок Oracle
Один из положительных моментов сотрудничества с Oracle состоит в том, что если Вы покупаете лицензии на миллионы долларов, то имеете шанс добиться большой скидки, даже более 50% от GPL (стандартного прайс-листа) [3]. При этом пропорционально изменяется и стоимость стандартной техподдержки.
Но и тут не обошлось без пары половников дегтя:
1. Скидка связана с конкретными Order Form, и покупка новых лицензий никак не влияет на стоимость СТП для лицензий, купленных ранее. Т.е. у Вас СТП на один и тот же продукт, купленный по разным Order Forms, может стоить по-разному. Если компания у Вас росла, росли объемы закупок, скидка увеличивалась, и Вы захотели платить меньше за СТП первых лицензий, то вариантов нет – пишите Termination Letter, отказывайтесь от них, потом покупайте их повторно, но уже с большей скидкой.
2. В то же время, отказ от части лицензий внутри одной Order Form приводит к перерасчету скидки на все продукты, купленные по этой Order Form. Алгоритм пересчета, если он вообще есть, известен только Oracle. Из опыта мне известно, что хотя стоимость СТП и не увеличивается, но может совсем не уменьшиться, делая бессмысленным отказ от небольшой части лицензий из одной Order Form ради уменьшения суммы СТП.
Goodbye, SUN
После покупки SUN Oracle начала распространять свою отработанную политику техподдержки на оборудование:
1. Сокращено количество вариантов техподдержки.
2. Введен штраф за пропущенный период техподдержки – как обычно, в полтора раза выше, чем стоимость ТП за тот же период.
3. Чтобы принудить всех купить техподдержку, сервисным центрам вообще запретили ремонтировать железо не проходящее по контракту техподдержки.
Заключение
Замечательные продукты разрабатывают в компании Oracle (говорят, только инсталляторы никак им пока не удаются), и взять их легко можно с официального сайта, и защиты от нелицензионного использования в них нет…
Но лучше все же внимательно прочитать лицензионное соглашение до начала разработки, чтобы не было потом неприятных сюрпризов.
Приходилось ли Вам реализовывать нестандартные решения? А в Oracle? Мне бы хотелось рассмотреть использование техник, позволяющих лучше узнать принципы работы СУБД, а в совокупности предоставляющие удобство для разработчика.
Намного удобнее, выполнять разработку приложений баз данных в едином пространстве, а результаты переносить по ландшафту системы в фоновом режиме, автоматически регистрируя производимые изменения.
Пример выполнения обновления на сервере разработки
Пролог
Вы встречали вредных DBA? А работали с такими? На самом деле, обе стороны (Developer vs. DBA), добиваются одного результата, работоспособности системы, но с разных сторон. Впрочем, когда система расширяется, децентрализуется, но сохраняет целостность в реализации, то поддержка консистентного состояния программной оснастки может начать доставлять серьезные неудобства. Появляются серверы разработки, тестирования, «продуктива» — и все это замечательно, но всех их нужно обновлять.
В Oracle есть инструменты казалось бы похожие на рассматриваемый:
• Audit
• Oracle Streams
• Alert
Но все они выполняют другие функции. Одни, обеспечивают аудит изменений, другие синхронизируют данные. А мне бы хотелось действовать более прозрачно, вот например:
Теперь все мои действия продублированы на сервере ‘prod’. А может быть, даже так:
И, скажем, семь серверов создали таблицу «A». Здорово? Тогда – поехали.
Подготовка
Выполним соединение с базой данных от имени пользователя имеющего достаточные привилегии для последующих действий:
Предполагается что пользователь, выполняющий обновления, не должен иметь доступа к самой системе обновления, впрочем, как и сама система не привязывается к целевой схеме, следовательно, может использоваться универсально. Поэтому создадим нового пользователя:
Поскольку статья не об ограничении прав новых пользователей:
Опустив рассуждения о проводимых изысканиях, скажу, что самым сложным оказалось получение анонимного PL/SQL блока, который приводился в примере выше. Естественно, одни действия в конечном итоге порождают другие, так например, всё тот же блок из примера, выполнит insert, но на самом деле может быть и не выполнит! Ведь выполняться он будет на другом сервере. Поэтому нас будет интересовать именно анонимный PL/SQL блок, а не последствия. Паблик синоним V$SQL или представление V_$SQL на которое он ссылается, хранит все запросы, выполнявшиеся на сервере. Попробуем найти в нём нашу цель:
Действительно, именно мой анонимный блок находится там где положено. Конечно же, SQL_ID выполняя мой пример, будет другой, но принадлежит ли он мне? Проверим:
Выполнившийся блок, удалось найти, но мне бы хотелось узнать, кем он выполнен, а точнее узнать, что именно я выполнял его в определенный момент времени. Другое представление V_$SESSION, сможет мне в этом помочь:
select sql_id, prev_sql_id from v$session;
Тут нужно пояснить, что синоним v$session предоставляет доступ к VIEW, а доступ для пользователя организуется командой:
grant select on v_$session to upd;
Дело тут в том, что тип представление v_$session является FIXED VIEW, поэтому давать права на его синоним – запрещено. Впрочем, если выдавать права на синоним, скажем таблицы, сами права выдаются на таблицу, а НЕ на синоним.
Так что же там с запросом? Ах да, нужно ограничить выборку текущей сессией:
Как это у Вас, не получается? Ни SQL_ID ни PREV_SQL_ID – не содержат найденного ранее идентификатора 753c9f808k8hh? Естественно! SQL_ID содержит идентификатор только что выполненного запроса, а PREV_SQL_ID скорее всего хранит идентификатор запроса:
Я надеюсь, что читатель последовательно выполнял запросы, как я их приводил и поэтому сразу не нашел того что ожидалось. Для того что бы убедиться, что результат будет как и указано, нужно выполнить последовательно анонимный блок и запрос к представлению. Как бы то ни было, считаю, что еще один этап изысканий пройден. Теперь мы имеем исходный текст анонимного блока, и знаем, что он был выполнен именно нами.
К сожалению, решение, которое автоматизирует связывание, мне не нравится, ведь необходимо после определенного момента, запомнить все возможные анонимные блоки выполняющиеся пользователем, а представления хранящего историю сессии пользователя не существует? Или существует? Впрочем я не нашел и на данный момент, предлагаю следующий подход. Создадим таблицу, которая будет хранить идентификатор сессии, которая заинтересована в прослушивании и джоб, опрашивающий эту таблицу и сохраняющий историю сессии.
«Что за названия полей второй таблицы?» — спросил бы я. Несмотря на то, что это не имеет веского оправдания, но пытавшись минимизировать нагрузку создаваемую джобом, я добрался до представления более высокого уровня sys.x_$ksuse которое содержит достаточную информацию о целевой сессии. Делая закладку на будущее, в таблицу будут сохраняться еще несколько полезных полей, помимо необходимых: KSUSENUM (SID) и KSUSESQI (SQL_ID). Хорошо будет вынести тело джоба во внешнюю процедуру, и не добавлять ее в пакет, дабы избежать ошибок, если пакет будет не валиден:
Идея обработки, заключается в том, что бы записывать в историю сессии только тогда, и только то что выполняется пользователем в режиме обновления. Теперь можно создать джоб, прослушать сессию пользователя и проверить результат:
Как видно из результата запроса к V$SQL анонимный блок попал в таблицу лога записанный туда джобом. Для теста, я обращался к столбцу KSUSEPSI лога (предыдущему запросу) ввиду того, что мне приходилось выполнять команды очистки таблицы сессии в момент прослушивания. В дальнейшем, это так же окажется некоторым недостатком, но «обрывание» прослушивания мы исключим из результирующего набора выполняемого на удаленном сервере.
Теперь необходимо собрать DLL команды, которые так же могут выполняться при обновлении. Но здесь происходит противоречие, зачем собирать DDL – если их соберет джоб? К сожалению, он их не соберет, так как DDL не является запросом, а следовательно в v$session не отразится. Для этих целей Oracle предоставляет триггеры уровня СУБД, которыми можно воспользоваться. Выполняемые DDL, запишем в новую таблицу, а по аналогии с джобом, создадим процедуру и триггер выполняющей её:
Дополнительная таблица, и её тип (GLOBAL TEMPORARY хранить данные до дисконнекта), выбраны из следующих соображений: джоб собирающий информацию о сессии, работает в сессии отличной от той, которая выполняет скрипты обновления, следовательно запросы записанные в нее стали бы недоступны сессии исполнителя; предоставить Oracle очистку таблицы после обновления; DDL триггер, срабатывает в той же сессии, в которой выполняется DDL, следовательно в этом случае записывать можно сразу в таблицу буфера; сохранение данных таблицы после коммита обусловлено тем, что DDL выполняет молчаливый коммит.
Важно обратить внимание на то, что процедура объявлена с директивой AUTHID DEFINER, которая позволит записывать действия с правами пользователя UPD, которые могут быть большими, чем у вызывающего. Далее производится определение длинны DDL и сохранение буферов в поле CLOB.
Триггер выполняется после (AFTER) DDL, что подразумевает успешное выполнение команды, до записи в буфер.
Подводя итоги изысканий, теперь имеются все возможные типы операций, подлежащие выполнению на обновляемой базе и можно приступить к завершающему этапу – инструменту выполнения обновлений.
Реализация
Мне не нравятся публикации, которые после длительного рассуждения и подготовки заканчиваются чем то вроде: «А теперь, (если не дурак) тебе должно быть ясно как доделать оставшуюся фигню». Конечно же тут дураков – нет, все давно поняли что нужно сделать дальше. Но я приведу свою текущую реализацию, несмотря на то, что её можно считать бета версией. Теперь много кода, а затем пояснения:
К ранее созданным таблицам, добавились еще две, одна из которых используется для визирования успешно выполненных обновлений, а вторая для настройки соединения с удаленной базой Oracle.
Пакет объявлен с директивой AUTHID CURRENT_USER – что приведет к выполнению процедур пакета, с правами пользователя вызывающего пакет. Теперь, о всех процедурах пакета:
procedure SetSession(u_sid number, u_remove boolean default false) – используя автономную транзакцию, записывает текущий идентификатор сессии в таблицу инициирующую прослушивание.
function JobNumber return number – получает идентификатор джоба прослушивателя.
procedure JobRun – проверяет существование джоба.
procedure SetChannel(u_alias varchar2) – получает настройки удаленного соединения и записывает их в локальные переменные пакета.
procedure CancelUpdate – стирает настройки и очищает временные таблицы.
procedure BeginUpdateChannel(u_alias varchar2) – объединяет вызовы подготовительных процедур и начинает прослушивание.
procedure PrepareUpdateChannel – завершает прослушивание и дописывает в таблицу буфер собранные джобом запросы сессии. Я для собственных нужд, не слишком стараясь, отбрасываю при этом DML, select и встреченные в процессе тестирования служебные команды, а так же вызов процедуры PrepareUpdateChannel который тоже записывается в лог сессии.
procedure DropObject – вспомогательная процедура для очистки.
procedure ExecRemote – выполнение блока на удаленном сервере. Эта процедура реализует один из ключевых моментов механизма. Тут пакет dbms_sql вызывается на удаленном сервере.
procedure EndUpdateChannel – применение обновления. И об этом отдельно.
Для конечного пользователя можно создать процедуры обертки, с директивой AUTHID DEFINER и раздать права вызывать их нужным пользователям:
В последние годы межплатформенная миграция Oracle Database перестала быть уникальной задачей. Компании, как правило, переезжают с рисковых платформ на x86, хотя бывает и наоборот. В этом посте поделимся нашим опытом межплатформенных миграций и подробнее остановимся на описании относительно нового способа физической миграции — расширении TTS.
Finding a Patch or Document When You Know Its Number
Третий вопрос — окно простоя
Вернемся к теме миграции. Есть три принципиально разных подхода к переносу Oracle Database между платформами:
- Логическая миграция. Классический Export/Import, Data Pump, SQL-команды через Database Link. При этом способе между платформами переносятся не файлы данных, а сами данные. Этот вариант проверен временем и относительно несложный. Он имеет всего одно ограничение: время простоя базы данных получается очень большим.
- Физическая миграция — Transportable Tablespace или TTS. При физической миграции между платформами переносятся файлы с данными, что значительно быстрее. Созданные на одной платформе файлы подключаются к базе данных на другой, поэтому необходимо тщательное тестирование, в том числе на предмет внутренних ошибок Oracle. TTS имеет сравнительно небольшое количество ограничений, а способы их обхода хорошо документированы.
- Репликация. Как правило, используется Oracle Golden Gate, хотя это не единственное решение. В основе любой репликации лежит разбор транзакционных журналов на базе-источнике с последующим применением (возможно с трансформацией) на базе-приемнике. Несмотря на развитые средства верификации данных (Oracle вместе с Golden Gate предлагает специальное ПО Veridata), остается серьезный риск потерять данные и не заметить это. Получается, что за целостность перенесенных данных в случаях логической и физической миграции отвечает Oracle, а в случае репликации — исполнитель.
Миграция с помощью TTS создавалась, чтобы быстро переносить оракловые файлы в рамках одной платформы. Уже потом она была расширена функционалом конвертации из одного Endian-формата в другой (технология RMAN Convert). Такая миграция состоит из трех этапов:
- выгрузка метаданных из словаря старой базы;
- перенос файлов данных с конвертацией RMAN;
- загрузка метаданных в словарь новой базы.
Это важно по следующей причине. Начиная с 12 версии RMAN (сама БД при этом быть версии 11) появилась возможность переносить и конвертировать не файлы с данными (что требует недоступности базы на все время переноса), а файлы бекапа (Backup Set). Это позволяет сделать полный бекап и восстановить его на новой платформе без остановки базы данных, а в технологическое окно перенести инкрементальный бэкап — «сконвертировать дельту». Такой способ намного быстрее переноса целой базы. Более того, можно повторить перенос инкрементального бэкапа несколько раз, пока «конвертация дельты» не начнет умещаться в заданное бизнесом технологическое окно.
Такой относительно новый функционал RMAN получил несколько названий, самое точное из которых, на наш взгляд — Cross-Platform Backup/Restore. С его помощью можно сократить время простоя, необходимое для конвертации: особенно если конвертируемые файлы Backup Set расположить на специальной файловой системе Veritas, допускающей переключение между платформами. При этом время выгрузки и загрузки метаданных данный способ не уменьшает!
Finding Patches on My Oracle Support
To find a patch on My Oracle Support when you know its number, do the following:
Select My Oracle Support (requires Flash) and log in.
The My Oracle Support portal opens, displaying general news from several categories.
Click the Patches and Updates tab.
The Patches and Updates page opens.
Click the Simple Search link.
In the Search By drop-down list, select Patch Number/Name and enter the number in the blank field.
In the Platform or Language drop-down list, select your platform and click Go . The system returns the search results in the table in the lower part of the screen.
My Oracle Support displays the patch screen.
Oracle Metalink и наш SR
Кто регулярно сюда заглядывает, те помнят о проблеме, по которой мы обращались на Metalink. Так вот проблема разрешилась. мной. Далее подробнее.
Во-первых: по той простой причине, что утилита сбора информации (кажется RDA) собрала все данные о всех инстансах на этом сервере, мы подумали, что оракловые спецы параметры конкретных экземпляров проанализировали, и сами сравнивать досканально не стали.
Во-вторых: забавно (почему, опишу чуть ниже), но пересоздание инстанса не помогло.
Итак, спец с Oracle Metalink предположил, что это действительно баг, который нигде пока не описан и надо бы его проработать, однако попросил поставить последний PatchSet 9.2.0.8, а вдруг там уже поправили ("Kindly note that this issue may be already fixed in 9.2.0.8"). К сведению, на том сервере был 9.2.0.5, после возникновения проблемы пропатчили до 9.2.0.7 (восьмого на тот момент не было, а качать немало). Короче все же поставили на закачку восьмой, но я решил сравнить параметры двух баз на одном сервере (теоретически все параметры за исключенем распределения памяти и всяких мелочей должны были быть идентичны). И нашел забавный момент (наименования инстансов изменены):
(DBError падает на обновлении MView, DBWorks работает без проблем):
DBWorks DBError circuits 0 170 mts_circuits 0 170 mts_servers 0 1 mts_sessions 0 165 shared_server_sessions 0 165 shared_servers 0 1
Очень похоже на то, что DBError работает в Shared Mode, но(!) на самом деле это не так. Вобщем как-то так получилось у моих предшественников, что параметры многие настроены под работу в режиме разделяемого сервера, но в этот режим он не переключен.
Your source for the latest information about Oracle Clinical 4.6 is Oracle Support's self-service website My Oracle Support and its predecessor, Classic MetaLink, available at the same URL at the time of publication of this document. Visit the site before you begin installing or upgrading this release. The site includes the latest information, including these important installation topics:
Oracle Life Sciences Applications Supported Technology Stacks (Document ID 180430.1).
Any changes to the instructions in this guide are documented in the most current version of the Oracle Clinical 4.6 release notes (Document ID 859753.1).
The latest patches.
Finding Documents on My Oracle Support
To find a document on My Oracle Support when you know its number, do the following:
Select My Oracle Support (requires Flash) and log in.
The My Oracle Support portal opens, displaying general news from several categories.
Click the Knowledge tab.
Check the top of the page. If PowerView is on and a product other than Oracle Clinical 4.6 is displayed, turn PowerView off.
In the Browse any Product, By Name drop-down list, select Oracle Clinical and click the icon.
In the Oracle Clinical Search section, enter the document ID and click the search icon.
Новая старая миграция
Новый способ миграции по сути является расширением TTS и на сегодня недостаточно документирован. Чтобы изучить его, необходимо читать синтаксис конкретных команд RMAN. Поэтому поделимся общей процедурой Cross-Platform Backup-Restore, реализованной нами в нескольких конкретных проектах миграции с рисковых платформ на x86.
Ниже приведены основные шаги этой процедуры. При создании скриптов миграции конкретных баз мы активно использовали генерацию текстов команд из SQL *Plus во всех случаях, когда необходимо перечисление файлов данных либо табличных пространств.
- Проверки перед миграцией. Проверки для классического TTS изложены в Metalink-ноте 371556.1 и для Cross-Platform Backup/Restore они в целом такие же. Особое внимание следует обратить на пользовательские объекты в табличном пространстве SYSTEM, которое при TTS не переносится и на режим Block Change Tracking.
- Создание базы данных на целевой платформе с правильной кодировкой и Timezone.
- Выполнение на исходной базе полного бекапа (level0) с помощью RMAN-команд Backup Incremental Level 0 Datafile ‘номер_файла’ Format ‘формат_backup_set’.
- Перенос пользователей с исходной базы в целевую базу: временное создание табличных пространств, перенос пользователей утилитами expdp/impdp, удаление табличных пространств (таким образом удается перенести пользователей до того, как табличные пространства будут перенесены TTS).
- Генерация на исходной базе скрипта по раздаче привилегий пользователей.
- Восстановление целевой базы из перенесенного полного бекапа (level0) с помощью RMAN-команд Restore From Platform ‘название_исходной_платформы’ All Foreign Datafiles Format ‘формат_backup_set’ From Backupset ‘имя_backup_set’. Название исходной платформы следует писать строго как в таблице Endian-форматов (см. начало статьи) — например, для Power/AIX это AIX-Based Systems (64-bit).
- Выполнение на исходной базе инкрементального бекапа (level1) с помощью RMAN-команд Backup Incremental Level 1 Datafile ‘номер_файла’ Format ‘формат_backup_set’.
- Применение на целевой базе перенесенного инкрементального бекапа level1 c помощью RMAN-команд Recover From Platform ‘название_исходной_платформы’ Foreign Datafilecopy ‘формат_backup_set’ From Backupset ‘имя_backup_set’. Шаги 1-8 можно делать вне технологического окна. Далее перечислены шаги процедуры миграции, требующие простоя.
- Перевод табличных пространств исходной базы данных в режим READ ONLY с помощью SQL-команд Alter Tablespace имя Read Only.
- Выполнение на исходной базе инкрементального бекапа (level1) с помощью RMAN-команд Backup Incremental Level 1 Datafile ‘номер_файла’ Format ‘формат_backup_set’.
- Параллельно п. 10 выгрузка из исходной базы метаданных пользователей утилитой expdp. Мы используем параметры «content=metadata_only exclude=user,role,role_grant,profile»).
- Параллельно п. 10 выгрузка из исходной базы метаданных табличных пространств утилитой expdp. Мы обычно используем параметры «exclude=table_statistics,index_statistics transport_full_check=no transport_tablespaces=список_табличных_пространств» т. к. выгрузка статистики оптимизатора часто оказывается долгой, особенно в базах данных 12 версии. В этом случае статистику нужно либо перенести пакетом DBMS_STATISTICS, либо частично собрать на целевой базе.
- Применение на целевой базе перенесенного инкрементального бекапа level1 (это второй инкрементальный бекап, выполненный в окно простоя) c помощью RMAN-команд Recover From Platform ‘название_исходной_платформы’ Foreign Datafilecopy ‘формат_backup_set’ From Backupset ‘имя_backup_set’.
- Загрузка в целевую базу метаданных табличных пространств, метаданных пользователей утилитой (оба действия — утилита impdp) и раздача пользователям привилегий (созданный в п. 5 скрипт).
- Перевод табличных пространств целевой базы данных в режим READ WRITE с помощью SQL-команд Alter Tablespace имя Read Write.
- Проверка INVALID объектов целевой базы данных и при необходимости их компиляция. Это последний шаг описанной процедуры. На этом межплатформенная физическая миграция с помощью Cross-Platform Backup/Restore завершена!
Автор: Алексей Струченко, руководитель направления СУБД «Инфосистемы Джет»
Первый вопрос — Endian-формат
PLATFORM_NAME | ENDIAN_FORMAT |
Oracle Solaris on SPARC (32-bit & 64-bit) | Big |
AIX-Based Systems (64-bit) | Big |
HP-UX (64-bit) | Big |
HP-UX IA (64-bit) | Big |
IBM zSeries Based Linux | Big |
Apple Mac OS | Big |
IBM Power Based Linux | Big |
HP Tru64 UNIX | Little |
Linux IA (32-bit & 64-bit) | Little |
HP Open VMS | Little |
Microsoft Windows IA (32-bit & 64-bit) | Little |
Oracle Solaris on x86 & x86-64 | Little |
Linux 64-bit for AMD | Little |
Microsoft Windows 64-bit for AMD | Little |
В последних версиях Oracle Database задача миграции между платформами с одинаковым Endian-форматом стала заметно проще. Как правило, работа Oracle Data Guard (Physical Standby) между такими платформами сертифицирована. Миграция через Standby хорошо документирована, требует минимального простоя базы данных и имеет прозрачную процедуру отката (обратный Switchover), если что-то пошло не так. Обычно такую миграцию компании выполняют самостоятельно.
Finding the Latest Oracle Clinical 4.6 Patches
Check My Oracle Support for the latest patches. If there are any new patches, follow these instructions to download them:
Select My Oracle Support (requires Flash) and log in.
The My Oracle Support portal opens, displaying general news from several categories.
Click the Patches & Updates tab.
The Patches and Updates page opens.
Click the Advanced Search link. When the Advanced Search page opens, enter appropriate search criteria and click Go .
When the query results are displayed, click a patch number to download it and view the readme file.
Читайте также: