Дс офу в r12 что это

APPS-ORACLE.RU

R12: таблицы HZ (Заказчики)

Рассмотрим назначение основных HZ таблиц и связи между ними.

HZ_PARTIES

Содержит основную информацию о сущностях (сторонах). Разные сущности могу иметь одинаковое имя.

HZ_PARTY_SITES

Служит для связи сущностей (HZ_PARTIES) и местоположения (HZ_LOCATIONS), также содержит дополнительную информацию о месторасположении.

HZ_LOCATIONS

Содержит данные об адресах.

HZ_CUST_ACCOUNTS

Содержит данные о счетах клиентов (заказчиков).
В качестве клиента может выступать организация или лицо.
Организация может быть внешней или внутренней (подразделение фирмы).
Одна сущность PARTY может иметь несколько записей. Например, физическое лицо может открыть персональный счет и семейный счет.

HZ_CUST_ACCT_SITES_ALL

Содержит адреса отделений заказчиков в разрезе операционных единиц.

HZ_CUST_SITE_USES_ALL

Содержит назначение адресов. Например BILL-TO, SHIP-TO.

HZ_CUSTOMER_PROFILES

Содержит информацию о кредитных характеристиках заказчика

HZ_CONTACT_POINTS

Содержит информацию о различных типах связи : телефон, e-Mail, EDI.

Источник

Внедрение Oracle ERP в «Ростелекоме»: экватор пройден

Реформирование холдинга «Связьинвест» в форме присоединения означает не только простое объединение юридических лиц в единую компанию, но и увязку всех работающих информационных систем в единую инфраструктуру. Первого апреля 2011 года появилась объединенная компания «Ростелеком». Эта дата и стала точкой старта проекта внедрения Oracle E-Business Suite R12 во всей компании.

В качестве системы управления предприятием у оператора использовалась Microsoft Axapta в связке с решением для управления кадрами «Босс-Кадровик». Присоединяемые МРК, входившие в холдинг «Связьинвест», пользовались комплексом Oracle E-Business Suite R11i. Разные учетные системы стали бы естественным препятствием в процессе создания объединенной компании. Для достижения целей унификации бизнес-процессов «Ростелекома» было принято решение развернуть единую ERP-платформу. Oracle E-Business Suite R12 была выбрана благодаря ее схожести с системами R11i, а также по причине заложенного в ней мощного потенциала в области управления предприятием.

Реализация программы идет по методологии внедрения Application Implementation Method for Business Flows (AIM for BF), предлагаемой Oracle. Подрядчиком в результате конкурса стала компания AT Consulting, имеющая статус платинового партнера вендора.

На первом этапе прошло пилотное внедрение в трех операционных единицах (Корпоративный Центр, Филиал «Столичный», Учебно-производственный Центр). Кроме того, система запущена в МРФ «Центр» и «Дальний Восток». Впоследствии планируется поэтапное развертывание системы в макрорегиональных филиалах «Волга», «Сибирь», «Урал», «Северо-Запад», «Юг».

Проект заметно отличается от классического внедрения информационной системы не только благодаря своим масштабам, но и проходящим одновременно с развертыванием организационным изменениям в «Ростелекоме». Подробности хода проекта с позиций заказчика и подрядчика освещают Дмитрий Казаринов, директор департамента проектов по развитию корпоративных систем поддержки бизнеса «Ростелекома», и Михаил Нелькин, руководитель проекта в AT Consulting.

Интервью с топ-менеджером

CNews: Почему вы выбрали именно Oracle, несмотря на то, что в центральном офисе уже использовалось решение другого вендора?

Дмитрий Казаринов: У этого проекта длинная история, связанная с реорганизацией активов «Связьинвеста». Объединение произошло вокруг «Ростелекома» как юридического лица, и межрегиональные компании (МРК) стали макрофилиалами. Соответственно, Axapta использовалась небольшой частью бизнеса, а в крупных операционных единицах, бывших МРК, как раз был Oracle предыдущей версии. Собственно, система была востребована, но вариант реализации был с большим уклоном в финансовую часть, а не ERP в классическом понимании. Кроме того, в связи с тем, что «Связьинвест» был холдингом, а не единой компанией, логика внедрения подразумевала семь изначально унифицированных, но обособленных систем. В каждой МРК система эволюционировала по-своему, а для объединенной компании этот вариант был неприемлем. Новые задачи объединенного бизнеса, развитие новых направлений, требовали реинжиниринг процессов.

Дмитрий Казаринов: От подрядчика мы требуем, прежде всего, гибкого, объективного подхода и профессионализма

Стоит отметить, что внедрение R12 в какой-то степени поддерживает процесс объединения с юридической точки зрения. В прошлом году в ходе создания тиражируемого решения в формировании целевых бизнес-процессов и информационных аналитик приняли участие все ключевые подразделений компании. Они по-новому выстроили уровни иерархии и формализовали функции.

CNews: Известно также, что это не единственный проект, который вы делаете с AT Consulting. Чем руководствовались при выборе подрядчика? По каким критериям «Ростелеком» вообще выбирает подрядчиков для подобных работ?

Дмитрий Казаринов: Рынок внедренцев ИТ-систем подобного масштаба не так велик. Это очень сложный бизнес. Обычно в больших корпорациях, несмотря на осознание необходимости систем такого уровня, непросто построить внутренний процесс. Проекты затрагивают очень много участников, порождают немало спорных моментов, поэтому подход простого консультанта здесь недостаточен и недопустим. В противном случае, проекты затягиваются или замораживаются вовсе, накапливается взаимное неудовольствие.

Подобные внедрения требуют очень серьезной бизнес-экспертизы. В какой-то степени подрядчик должен быть столь же компетентным в функциональной области, как и заказчик. Большие системы обычно поставляются зарубежными вендорами и требуют кастомизации, адаптации без потери качества данных и процессов под логику, свойственную большому юридическому лицу. Здесь, действительно, очень важен подход внедренцев не как людей со стороны, а как команды, по-настоящему болеющей за дело.

CNews: Расскажите подробнее о наследуемых системах. Каково было положение дел?

Дмитрий Казаринов: На самом деле парк систем большой. ERP использовалась больше для учета. Были и самописные продукты, касающиеся финансового блока и планирования, разнообразные системы документооборота и согласования договоров. Набор типичен для компании такого масштаба, но в каждом макрорегионе применение было свое. Поэтому развертывание R12 мы начали с ядра в центре. Целевая система появилась не на пустом месте. Ряд макрорегионов имеет очень высокую компетенцию по всем этим направлениям. В частности, макрорегион «Центр» имеет хорошую компетенцию по Oracle. Таким образом, ERP выступает как центральная система, вокруг которой создается среда финансовых систем и СЭД. Так, бюджетирование и планирование централизовано обслуживается Oracle Hyperion, а документооборот делается на EMC Documentum. В целом это функциональность ERP, она набирается из модулей, которые нам подходят, но и методологически, и с точки зрения технологической интеграции все это делается как единый instance, обеспечивая целостность и достоверность данных.

Источник

Русские Блоги

Oracle EBS R12 учебная среда

каталог

Чтобы изучить систему EBS, вам нужно иметь случайную среду для изучения и тестирования.
В Интернете существует множество учебных пособий, возможно, в период между 2008 и 2014 годами, в основном на основе текстовых описаний, и я не понял этого после длительного чтения.
Официальный представитель Oracle недавно вышел из виртуальной машины с установленной EBS, вы можете загрузить ее напрямую, а затем залить ее на свой ПК, попрактиковаться в использовании, очень удобно, этот блог является записью всего процесса.
Я скачал последнюю версию, и она была успешно построена.

Требования к оборудованию

Оборудование виртуальной машины

Память: 12 ГБ +
Жесткий диск: 300 ГБ +
Процессор: 4 потока +

Хост-машина (локальная машина)

Информация о хосте автора выглядит следующим образом:

Модель: MacBook Pro (Retina, 15-дюймовый, середина 2015 г.)
OS：MacOS high Sierra 10.13.6
Процессор: Intel Core i7 2,2 ГГц (4 ядра 8 потоков)
Память: 16 ГБ, 1600 МГц, DDR3
Жесткий диск: мобильный жесткий диск 256SSD + 1T

Подготовка файла

Необходимо подготовить носитель виртуальной машины Oracle и программное обеспечение виртуальной машины.

Установочный носитель

Носители виртуальных машин можно загрузить с официального сайта Oracle, перед загрузкой необходимо зарегистрировать учетную запись и войти в систему.
Примечание. Загрузка не имеет права сразу после завершения регистрации, как правило, более одного рабочего дня.

Зарегистрироваться и войти в систему

Скачать медиа

1 открытыйhttp://edelivery.oracle.com/
2 Поиск виртуальных устройств Oracle VM для Oracle E-Business Suite
3 Нажмите соответствующую версию, чтобы добавить ее в корзину

4 Нажмите на корзину для загрузки:

5 Нажмите «Продолжить» и примите соглашение об обслуживании

6 Загрузите файл

Примечание. Он загружается через официальный загрузчик Oracle. Всплывающее окно загрузчика может быть по ошибке перехвачено браузером. Обратите внимание на подсказку.

Программное обеспечение виртуальной машины

Адрес:https://www.virtualbox.org/

Процесс установки: используйте конфигурацию по умолчанию, пошаговую установку

Импорт виртуальной машины

Медиа слияние

1 Распакуйте 19 сжатых пакетов в одну папку
2 Объедините файлы 18 ova (т. е. xx.ova.00-xx.ova.17 в файлы xx.ova)

Процесс слияния: откройте командную строку CMD, переключитесь на букву диска и каталог, где находится носитель (например, G: // VMS)
Сценарий слияния

Импорт виртуальной машины

1 Откройте VirtualBox и импортируйте

Выберите путь к файлу ova для импорта.
Обратите внимание, что конфигурация, отмеченная красным, является путем хранения виртуальной машины и может быть изменена. Свободное место на диске должно быть больше 300 ГБ.

Нажмите «Импорт», программа преобразует файл ova размером 65 ГБ в файл виртуальной машины объемом 270 ГБ, который можно запустить.
Обратите внимание, что это не повлияет на исходный файл ova.
Весь процесс импорта занимает около 150 минут (при условии механического жесткого диска USB3.0)

Первая загрузка конфигурации

Запустите виртуальную машину

Примечание. При первом включении компьютера вы можете получить сообщение об ошибке в настройках сети. Нажмите «Изменить настройки», затем ничего не меняйте и нажмите «ОК».

Установить пароль пользователя

Введите интерфейс входа
ввод

Система предложит установить пароль для пользователя root, введите один раз, введите один раз еще раз
Затем установите пароли для пользователей Oracle (владельцев баз данных и приложений) и пользователей applmgr.

Установите приложение DB & EBS

После установки пароля программа автоматически исправляет соответствующие файлы и устанавливает службу базы данных и приложение EBS, что занимает около 20 минут.

Открытый сервис

Переключить пользователей

Переключиться от пользователя root к пользователю oracle. Пользователь oracle имеет разрешение на выполнение связанных сценариев, а для непосредственного использования root требуется изменение разрешений, что не рекомендуется.

Откройте базу данных

Перейдите в каталог скриптов,Запустите startdb.sh

Весь процесс занимает около 2 минут.
Обратите внимание, имеет ли статус выхода 0 (нормальный)

Откройте сервис приложений ebs

Это занимает около 20 минут (в зависимости от выделенных системных ресурсов, автор составляет 12 ГБ + 4 потока + механический жесткий диск)

Включить DEMO user и sysadmin (максимальное пользовательское право ebs)

Доступ к системе возможен как обычно, но вы не можете войти в систему без правильного имени пользователя и пароля.
В каталоге сценариев выполните следующие команды для установки паролей пользователей.

Это займет около 5 минут.

Внешний доступ

Регулярное использование

Вам необходимо установить его в первый раз, а затем регулярно использовать сервер. Вам нужно всего лишь войти в каталог скриптов и выполнить запуск БД и APP.

Внешнее соединение

Получить IP

Запустите ifconfig на виртуальной машине, чтобы получить IP-адрес

Установить статический IP

После каждого перезапуска IP-адрес виртуальной машины может меняться, поэтому изменять файл hosts для обычного доступа к хосту неудобно. Может быть установлен на статический IP

Установите, чтобы разрешить удаленное соединение SSH

Разрешение экрана виртуальной машины нелегко настроить, и команды не могут быть скопированы, что не способствует работе. Установка удаленного соединения SSH может быть легко связана с различными инструментами SSH хост-машины.
Измените следующую конфигурацию

Обновить конфигурацию сейчас

Хост доступ

настройки хостов

Прочитайте конфигурацию файла hosts на виртуальной машине

Добавьте последнюю строку в локальный файл hosts.

Доступ через браузер

Адрес:http://apps.example.com:8000/

Подключение к базе данных

Аккаунт: приложения
Пароль: приложения

Источник

Основные нововведения Oracle 12 R2: Рывок вперед или эволюция?

Основные нововведения Oracle 12 R2: Рывок вперед или эволюция?

Руководитель Центра Компетенции по базам данных УКЦ ФОРС

Основные нововведения Oracle 12 R2: Рывок вперед или эволюция?

Уважаемые коллеги и друзья!

Уже несколько месяцев прошло с тех пор, как мы смогли впервые скачать такой долгожданный релиз 12.2. Это достаточный срок, чтобы ознакомиться с новым продуктом, протестировать его работу как в тестовом, так и (смельчаки всегда найдутся) в боевом окружении. Возможно, протестировать свое приложение или написать новое, увидеть разницу в планах запросов, обжечься на багах и применить новые патчи, наконец!

Да мало ли что бывает в нашей работе!

И это – достаточный срок, чтобы составить свое определенное мнение, основанное не на отзывах в форумах и статьях в известных (и не очень) журналах с разной степенью аффилированности, но на собственном опыте и опыте коллег, мнению которых я за годы работе в Форсе привык доверять.
И, кстати, меня, как специалиста, такая привычка еще никогда не подводила!

Oracle Database 12.2 представляет существенный апгрейд мультиарендной архитектуры БД, а также новый подход к процессингу информации ресурсами оперативной памяти. Нововведения предназначены для оптимизации ключевых рабочих нагрузок и их главных характеристик: производительности, безопасности и т.д. Общее число нововведений во втором релизе 12-й версии Oracle составляет около 300 различных усовершенствований буквально по всем важным направлениям работы.

Теперь, когда лирическое отcтупление завершено, перейдем к более подробному рассмотрению основной темы данной статьи – обзору основных нововведений Oracle database 12 R2.

Нововведения в Multitenant Container Database Architecture

1. Application Container

Представлена концепция контейнеров приложений, которая предлагает возможность иметь одно логическое определение для одного или нескольких приложений.

Каждый Application Container, по аналогии с CDB, имеет свой Application Root и Application Seed PDB, которые разделяют свои ресурсы среди PDB, содержащихся в этом контейнере. Подробнее про нововведения в контейнерных базах можно прочитать в нашей статье (ссылка)

2. Локальное UNDO в контейнерных БД

Интересное нововведение – возможность использования каждой подключенной базой своего локального UNDO. При этом, редологи, конечно, остаются общими для всех PDB в контейнере.

Для чего это нужно? Эта опция существенно облегчает горячее клонирование CDB и обеспечивает нулевое время простоя при переносе контейнеров.
Процесс перевода на использование локальных UNDO выглядит так:

SQL> STARTUP UPGRADE

SQL> ALTER DATABASE LOCAL UNDO ON;

3. Recovery и flashback контейнерных БД

Полезные нововведения появились и по части восстанавливаемости и flashback контейнерных баз.
Во-первых, появилась возможность остановки контейнера с параметром abort

SQL> ALTER PLUGGABLE DATABASE CLOSE ABORT;

В случае утери или порчи табличного пространства system PDB нам больше нет необходимости переводить весь контейнер в режим mount, что достаточно серьезно поднимает уровень доступности систем, где любое время простоя является неприемлемым.

Во-вторых, появилась возможность делать flashback database для отдельно взятой PDB, что ранее, на версии 12 R1, было недоступно ( только для всего контейнера).

Пример показывает конфигурацию и использование опции flashback database для отдельной PDB

SQL> SHUTDOWN IMMEDIATE

SQL> ALTER DATABASE ARCHIVELOG;

SQL> ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=2880 SCOPE=BOTH;
SQL> ALTER DATABASE FLASHBACK

Делаем flashback database для PDB:

RMAN> ALTER PLUGGABLE DATABASE CLOSE;

RMAN> FLASHBACK PLUGGABLE DATABASE pdb1 TO SCN 411010;

RMAN> ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS;

Концептуально, PDB открывается с помощью RESETLOGS также как и OPEN RESETLOGS для обычной БД. Информацию о реинкарнациях PDB можно посмотреть в новом динамическом представлении V$PDB_INCARNATION

Стоит обратить внимание, что PDB RESETLOGS не делает RESETLOGS в CDB, а только изменяет связанную с ней запись в общем контрольном файле!

Новое в управлении производительностью (Performance ) CDB и PDB

Oracle Database 12.2 вводит новый параметр для контроля уровня параллелизма в запросах, с помощью конструкции containers().

SQL> ALTER SESSION SET containers_parallel_degree = 12;

SQL> SELECT /*+ CONTAINERS (DEFAULT_PDB_HINT=PARALLEL 8*/ sum(revenue), year
FROM CONTAINERS(sales_data) WHERE year = 2014 GROUP BY year;

1. Появилась возможность использовать PDB-Level Snapshot Views, что было недоступно на 12.1:

SQL> SELECT view_name FROM dba_views WHERE view_name LIKE ‘%AWR%_PDB%’;

На рисунке показана архитектура и состав этих уровней для представлений в AWR :

ADDM, тем не менее, срабатывает только на уровне всего контейнера, как и отчеты AWR. Тем не менее, в отчете AWR мы можем увидеть детализированную статистику для всех контейнеров: для CDB root и каждой ОТКРЫТОЙ PDB
1. Индивидуальное управление памятью для подключенных баз

Пожалуй, самое важное нововведение в аспекте управления ресурсами – локальное управление памятью для каждой подключенной PDB.
До 12.2 мы никаким явным образом не могли заставить подключенные базы ограничивать использование областей памяти.
Единственный метод как-то ограничить ресурсы каждой PDB был Resource Manager, при использовании которого можно было изменить максимумы и доли используемых ресурсов внутри контейнера путем ограничения использования процессора.
Также была возможность регулировать I/O на уровне CDB, но этот функционал был доступен только для Exadata (до 12.2)
( В новой версии БД появились параметры:

· MAX_IOPS: Number of IOs issued per second

· MAX_MBPS: MB of IO issued per second)

Появился новый параметр SGA_MIN_SIZE – «минимальная гарантированная доля SGA» для PDB, причем сумма всех минимумов SGA для всех PDB не может превышать 50% от всей памяти контейнера.

Про PGA – тоже хорошие новости.

Параметры PGA_AGGREGATE_LIMIT и PGA _AGGREGATE_TARGET устанавливаются на уровне контейнеров точно так же, как и для обычных баз данных.
Ну не прекрасно ли!
Соответственно, появились и новые динамические представления для контроля за использованием памяти на уровне PDB.
Вот некоторые из них:

Ну, и наконец, 12.2 полностью стала поддерживать появившийся в 12.1 функционал Heat Map (т.н. «горячих карт») и расширений управления хранения данных согласно жизненного цикла (ADO Enhancements).
Включить данный функционал – очень просто. Достаточно прописать в параметрах строчку:

Новые привилегии и опции профилей.

Наряду с появившимися в Oracle Database 12.1 новыми системными привилегиями SYSBACKUP, SYSDG и SYSKM, призванными разграничить, в целях безопасности, административные полномочия, в 12.2 введена новая системная привилегия SYSRAC для управления кластером

• Не поддерживается файлом паролей

• Используется только CRS oraagent

Например:
SQL> grant sysrac to c##test;
*

ERROR at line 1:
ORA-28190: SYSRAC administrative privilege cannot be granted to other users

Также появилась новая группа OSRACDBA с возможностью аутентификации посредством OS*

*В Windows группа называется ORA_%HOMENAME%_SYSRAC

SYSRAC обладает следующими привилегиями:

ALTER DATABASE MOUNT

ALTER DATABASE OPEN

ALTER DATABASE OPEN READ ONLY

ALTER DATABASE CLOSE

ALTER SESSION SET EVENTS

ALTER SESSION SET _NOTIFY_CRS

ALTER SESSION SET CONTAINER

ALTER SYSTEM REGISTER

ALTER SYSTEM SET LOCAL_LISTENER

ALTER SYSTEM SET REMOTE_LISTENER

ALTER SYSTEM SET LISTENER_NETWORKS

SELECT X$ tables, V$ / GV$ views

dbms_ha_alerts_prvt
DEQUEUE sys.sys$service_metrics

Наконец-то претерпел изменения файл паролей! Теперь он имеет другой формат и несет больше информации.

– Статус аккаунта OPEN, LOCKED EXPIRED

– Время последнего успешного логина
– Используемый метод аутентификации ( LDAP,OS,password file)

Соответственно, изменился синтаксис утилиты orapwd:

Usage: file= … format= sys=

$ orapwd describe file=orapwcdb3
Password file Description : format=12.2

Тем не менее, утилита orapwd позволяет очень просто мигрировать с 12.1 и более ранних версий на файла паролей версии 12.2.
Пример использования можем посмотреть:

$ mv orapwcdb1 orapwcdb1.12

$ orapwd file=orapwcdb1 input_file=orapwcdb1.12 format=12.2

$ orapwd describe file=orapwcdb1

Password file Description : format=12.2

*Команда DESCRIBE утилиты orapwd также проверяет файл паролей на целостность

Нововведения в Data Redaction

Задача разделения доступа к данным в ИТ системах возникает всегда. Если доступ к базе данных возможен только из сервера приложений, то можно возложить эту обязанность на него. Но почти всегда есть потребность прямого доступа к данным, например для аналитиков и других привилегированных пользователей.
В Oracle 12c добавлена возможность изменять на выдаче значения полей (полностью или частично), в зависимости от неких, определяемых нами, условий. Эта возможность получила название Oracle Data Redaction и состоит в применении специальных политик.
В 12.2 Oracle опция Data Redaction получила значительные улучшения.
Если в 12.1, при создании политик, мы могли только определить
“how to redact”, то есть, каким образом изменить данные в выдаче, то
в 12.2 каждый столбец может иметь свою «policy expression».

То есть, Oracle Database 12.2 позволяет создать разные расширения для разных столбцов одной таблички или представления, или просто для отдельного столбца (например, номера кредитных карт)

Oracle Database 12.2 и опция Oracle Advanced Security предоставляют новую «библиотеку форматов данных Data Redaction».

Библиотека форматов хранится в репозитарии Enterprise Manager Cloud Control и содержит:

• Предустановленные варианты форматирования выдачи данных

Новое в шифровании данных

В Oracle Database 12.2 появилась возможность шифровать существующие табличные пространства.

· Пользовательские табличные пространства могут быть офлайн во время зашифровки.

· SYSTEM, SYSAUX, and UNDO – шифрование этих табличных пространств производится только на монтированной базе данных.

*Тут стоит заметить, что шифровать UNDO, если у нас зашифрованные данные в файлах бессмысленно, ибо попавшие в UNDO before-change данные уже будут зашифрованными!

**Можно создать зашифрованное Temporary табличное пространство, но зашифровать существующее – не получится!

Расширения RMAN, резервное копирование и восстановление.

1. Новые команды и расширения RMAN

Появилась возможность для обновления и удаления каталога восстановления одной командой:

RMAN> UPGRADE CATALOG NOPROMPT;

RMAN> DROP CATALOG NOPROMPT;

2. RESTORE and RECOVER

Команды RESTORE and RECOVER обычно идут последовательно, одна за другой, что, собственно говоря, логично.
Oracle Database 12.2 расширяет функционал команды RMAN REPAIR опциями DATAFILE, TABLESPACE, PLUGGABLE DATABASE and DATABASE и выполнением
RESTORE и RECOVER одной единой командой.

При этом, (если это возможно) REPAIR автоматически переводит файл данных в offline, извлекает из его бекапа (RESTORE), восстанавливает его (RECOVER) и потом переводит снова в состояние online!

Посмотрим на примере:

RMAN> REPAIR DATABASE;

RMAN> REPAIR PLUGGABLE DATABASE pdb1;

RMAN> REPAIR TABLESPACE example;
RMAN> REPAIR DATAFILE 12;

3. Неполное восстановление БД

Далее, появились интересные нововведения в операции неполного восстановления базы данных.

До 12.1 включительно, восстанавливая базу до последнего доступного архивного или редолога, мы могли пользоваться командой

RMAN> RECOVER DATABASE UNTIL CANCEL; (из SQL Plus или RMAN 12C)

После применения последнего доступного лога мы давали команду

RMAN> ALTER DATABASE OPEN RESETLOGS;

В 12.2 этот процесс автоматизирован, достаточно дать одну команду

RMAN> RECOVER DATABASE UNTIL AVAILABLE REDO;

И, в случае применения сотен или, не приведи бог, большего количества архивных логов, процесс восстановления пройдет гораздо быстрее.
При этом, конечно же, открытие БД с опцией RESETLOGS никто не отменял:

RMAN> ALTER DATABASE OPEN RESETLOGS;

Отрадно, что старый синтаксис не стал неиспользуемым, ибо как нам тогда малой кровью восстанавливать БД при утерянном redo log со статусом ACTIVE, который на наше счастье, успел заархивироваться?

Позволю себе небольшое лирическое отступление по этому поводу, или как «обмануть» Oracle!

Предположим, у нас неведомым образом утеряна группа лог файлов. Все!

Инстанс падает, мы монтируем базу и смотрим v$log.
Видим статус утерянных файлов журналов STATUS=ACTIVE и ARC=YES. То есть, лог файл не требует архивации, но НУЖЕН для recovery.

Если бы его статус был CURRENT (то есть, лог файл текущий), то БД можно восстановить только с помощью более раннего ПОЛНОГО бекапа на момент времени до утери CURRENT лог файла (группы).
В случае же, если статус лог файла INACTIV, то у нас вообще практически нет проблем. Данных, необходимых для восстановления инстанса в нем нет, файл заархивирован.
В этой ситуации мы просто пересоздаем его с помощью команды:

SQL> alter database clear logfile ‘/FILE_PATH’;

и открываем базу без RESETLOGS.

SQL> alter database open;

Возвратимся к нашему утерянному ACTIVE лог файлу.
Так как у нас есть архивная копия, то мы можем, применив ее, «перескочить» в процессе восстановления через утерянный лог файл и закончить восстановления применением текущего (CURRENT) редолога.

Если не идти по этому пути, то процесс восстановления будет таким же, как и при потере CURRENT редо лога, то есть, восстановление из прошлого бэкапа и накат архивов и редо логов.
Кошмар любого администратора и его руководителя…
На большой базе, или при применении большого количества архивных логов время простоя может быть просто неприемлемым!

Поэтому поступаем таким образом:

1. Переходим в SQL Plus (На 12 RMAN возможно использование командной строки RMAN, так как команды SQL Plus больше не надо выделять соответствующей нотацией)

2. SQL> alter database recover until cancel;

3. SQL> alter database recover continue default;

Применяем архивные логи, причем последним применяется архивная копия нашего трагически потерянного ACTIVE редо!

4. SQL> alter database recover continue default;

5. Тут мы предсказуемо получаем ошибку ORA-00308: cannot open archived log. RMAN ищет следующий архивный журнал, но не находит, так как редолог CURRENT не заархивирован!

6. И тут мы немного «обманываем» Oracle, подсовывая вместо архива, которого в принципе нет и быть не может, текущий CURRENT редо лог:

SQL> alter database recover logfile ‘/CURRUNT REDO LOG FILE’;

7. SQL> alter database open resetlogs;

8. Все! (фанфары, туш)
Мы, проведя НЕПОЛНОЕ восстановление, ПОЛНОСТЬЮ восстановили базу (по последнюю закоммиченную транзакцию)
Уф….

4. Восстановления отдельных таблиц

Теперь вернемся, друзья, к нашей теме, к 12.2.

Изменению подверглась возможность восстановления отдельных таблиц.
До 12.2 таблицы (партиции) восстановимы были только в пределах одной схемы. Remap мог изменить имя таблички, но не ее собственника.

В Oracle Database 12.2 это ограничение исчезло, причем касательно не только таблиц, но и всех зависимых обьектов ( индексов, ограничений, триггеров и т.д.)

RMAN> RECOVER TABLE hr.employees UNTIL SCN 2146235

AUXILIARY DESTINATION ‘/u01/app/oracle/backup_test’
REMAP TABLE hr.employees:hr_new.employees;

Полезным можно считать нововведение, когда при создании вспомогательного (auxiliary) инстанса для восстановления таблицы, Oracle автоматически проверяет наличие места на диске.
Читатели, кто попадал в подобные ситуации с нехваткой (как всегда, неожиданной) места, те поймут.
Если дискового пространства недостаточно, то сервер сразу сгенерит ошибку на уровне ОС и процесс восстановления просто не начнется.

Значительные изменения, заслуживающие отдельной статьи, которая, безусловно будет опубликована в ближайшем номере ФОРС magazin, произошли с возможностью переопределения таблиц, в частности, с пакетом DBMS_REDEFINITION.

В частности, в процедуре START_REDEF_TABLE параметр enable_rollback, который позволяет откатить все изменения до запуска FINISH_REDEF_TABLE.

Процесс выглядит следующим образом:

1. Проверяем, может ли таблица быть переопределена онлайн.

2. Создается промежуточная таблица.

3. Стартуем процесс переопределения (redefinition)

4. Завершаем процесс:
Откатываем изменения или применяем их:

SQL> EXEC DBMS_REDEFINITION.START_REDEF_TABLE (… ENABLE_ROLLBACK => TRUE)

SQL> EXEC DBMS_REDEFINITION.FINISH_REDEF_TABLE (… DISABLE_ROLLBACK => TRUE)

SQL> EXEC DBMS_REDEFINITION.ROLLBACK(…);

SQL> EXEC DBMS_REDEFINITION.ABORT_ROLLBACK(…);

И главным изменением в процессе оnline redefinition, безусловно, нужно считать возможность переопределения с «No Exclusive DML Locks»!

Полезные нововведения в Oracle Data Pump, SQL*Loader и внешних таблицах.

Oracle Data Pump в версии 12.1 базы данных Oracle поддерживает параллельный экспорт и импорт табличных данных, но обработка метаданных при этом производится одним процессов.
Data Pump в 12.2 сокращает время выгрузки и загрузки метаданных путем параллельного запуска нескольких фоновых процессов. Это новое усовершенствование позволяет ускорить процесс миграции больших баз данных. Параллельный экспорт и импорт метаданных активируется заданием параметра PARALLEL:

$ expdp … PARALLEL = n

При миграции таблицы, DBA иногда предварительно создает таблицу перед переносом ее данных, т. к. новая таблица может иметь новые атрибуты (например, сжатие) или другой вид партиционирования.
Импорт данные таблицы из секционированной таблицы в новую идет последовательно, по одной партиции за раз, потому что измененная структура новой таблицы может вызвать появление строк из одной экспортируемой партиции исходной таблички в нескольких партициях целевой.

Если же партиций много (не такой уж редкий случай на практике), то процесс импорта может быть неприемлемо долгим. Data Pump в 12.2 позволяет частично обойти это ограничение и загружать данные из нескольких разделов одновременно в следующих случаях:

· Если экспортируемые и импортируемые таблицы имеют тот же метод партиционирования и партиции поименованы одинаково.

· Если экспортируемые таблицы данных во всех секциях рассматривается как единое целое, т. е., импортируются параллельно с помощью конструкции INSERT AS SELECT.

2. Переименование файлов данных при использовании перемещаемых табличных

Безусловно полезная опция импорта по сети получила новый функционал – выбор и определения метода доступа к данных.
Данная возможность определяется параметром ACCESS_METHOD, который может принимать следующие значения:

· DIRECT_PATH: (теперь можно импортировать таблицы со столбцами с типом данных LONG)

Докучаев Дмитрий 2017г.

Продолжение рассказа о нововведениях Oracle Database 12 r2 – в следующем номере журнала FORS MAGAZIN

Источник