Создание пользователя cdb oracle
Обновлено: 02.07.2024
Думаю, настало время разобраться с тем как же создаются "схемы" в БД Oracle. Под понятием схема имеется ввиду сам созданный аккаунт или говоря прямо - пользователь БД! Целью создания пользователя как раз и является получение схемы БД, с определенными правами и привилегиями. Создание пользователя в БД Oracle достаточно не сложный, но в тоже время довольно концептуальный момент. Для создания пользователя (схемы), применяется команда DDL - CREATE USER. Она имеет следующий синтаксис:
- [пользователь] [Username] - Имя пользователя (название схемы).
- [пароль] [Password] - Пароль для учетной записи.
- DEFAULT TABLESPACE - Табличное пространство в котором будут находиться создаваемые в данной схеме объекты. Эта настройка не дает пользователю права создавать объекты - здесь устанавливается только значение по умолчанию.
- TEMPORARY TABLESPACE - Табличное пространство, в котором находятся временные сегменты, используемые в процессе сортировки транзакций.
- QUOTA - Позволяет пользователю сохранять объекты в указанном табличном пространстве, занимая там место вплоть до определенного в квоте общего размера.
К слову сказать, в чем мы далее и убедимся. Для того, чтобы запросы пользователей могли создавать временные сегменты в табличном пространстве TEMP, им не нужны квоты на дисковое пространство. Попробуем создать пользователя! Запускайте SQL*Plus с пользователем SYS или SYSTEM пароли администраторов смотрите в шаге 5! Из всего выше сказанного, запишем вот такую конструкцию:
Здесь мы создаем пользователя (схему) DUMMY с паролем DUMB и позволяем ему резвится на 100 Мб пространства USERS и еще немного выделяем из пространства TEMP. Получаем в результате:
Ок! Пользователь (схема) создан. Наверное, можно уже подключится и начать создавать объекты! Пробуем!
Именное такой синтаксис подключения можно использовать, он еще называется строка коннекта и расписывается вот так:
Опа! Не повезло! Создание пользователя - это еще не все! Теперь ему нужно разрешить самое основное - создавать сессию с сервером. Сделать это можно командой GRANT. Она достаточно объемная и мы ей займемся чуть позже, а пока восстановим подключение:
Даем пользователю право создавать сессию с сервером:
Вот теперь можно немного перевести дух. Итак, мы создали пользователя, определили ему табличные пространства, назначили квоты на них. И даже позволили создавать сессию с сервером. Давайте убедимся, что пользователь создан и чувствует себя нормально. Производим переконнект на админа БД:
Дадим такой запрос к представлению DBA_USERS:
Кто знаком с криптографией, может на досуге раскусить - E888ADB4D5FFE1B2 или хотя бы провести аналогию с DUMB! Итак, все с нашей схемой в порядке! Осталось только разрешить пользователю создавать объекты БД.
Да, так как оператор GRANT это DDL, то COMMIT вызывается не явно! В данном случае мы разрешили пользователю, создавать такие основные объекты БД как - TABLE, PROCEDURE, TRIGGER, VIEW, SEQUENCE. Для начала этого достаточно. А что делать, если пользователю будет необходимо изменять эти объекты? Тогда нужно добавить еще немного прав, на изменение (ALTER) вот так:
Вот теперь он может не только создавать эти объекты, но и изменять их! А, что если пользователю необходимо будет удалить какой-либо объект или удалить записи из таблиц? Тогда нужно добавить права на удаление объектов БД вот так:
Уфф! Ну вот теперь кажется все! Пользователь действительно полноценный и может работать! Помните в шаге 6 мы с вами это уже проделывали, но тогда я не вдавался в подробности, так как было не до того! А, вот теперь давайте разберемся более детально и продолжим далее.
На момент написания статьи официальный выпуск новой версии Oracle Database 12.2.0.1 еще не состоялся, но уже есть документация и возможность опробовать предварительную версию 12.2.0.1 RC4 от 14.09.2016 вживую в рамках курса Oracle University «Oracle Database 12c R2: New Features for 12c R1 Administrators». Здесь я поделюсь впечатлениями о том, что показалось наиболее интересным из тех возможностей, которые удалось опробовать.
Контейнерная архитектура
В 12c R2 контейнерная архитектура базы данных получила довольно существенное развитие. Если в 12c R1 удалось реализовать совместное использование компонент инфраструктуры (процессы, память, метаданные) среди слабо связанных между собой баз данных, то в 12c R2 через контейнеры приложений появилась возможность совместного использования метаданных и общих данных приложений. С другой стороны, появились новые инструменты распределения критичных ресурсов (память, ввод-вывод) между отдельными контейнерами. Архитектура начала приобретать свойство древовидности (с фиксированным количеством уровней).
Как видно из схемы (взята из документации), теперь мы можем в рамках CDB создавать корневые контейнеры приложений и в рамках таких контейнеров новый вид подключаемых баз данных — подключаемых баз данных приложений. Смысл создания нового уровня архитектуры, в первую очередь, состоит в том, чтобы уменьшить стоимость обслуживания однотипных баз данных, характерных для облачных вычислений.
Ключевым понятием данного слоя является понятие — Приложение:
- приложения первоначально устанавливаются в корневые контейнеры приложений;
- обязательными атрибутами приложения являются его имя и версия;
- в рамках инсталляции создаются общие метаданные и данные приложения;
- приложения в рамках одного корневого контейнера приложений устанавливаются строго последовательно;
- в один контейнер можно разместить несколько приложений.
При первом открытии корневого контейнера создается встроенное приложение с именем APP$GUID, где GUID — это глобальный идентификатор корневого контейнера приложений, и для него создается дополнительное логическое имя (или алиас) APP$CON.
Инсталляция приложения начинается с команды ALTER PLUGGABLE DATABASE APPLICATION name BEGIN INSTALL 'version'.
После начала инсталляции приложения начинается захват SQL кода, который выполняется в корневом контейнере приложений в рамках одной или нескольких сессий (так по документации, а пробной версии 12.2.0.1 такой захват в рамках нескольких сессий производился некорректно). Кроме обычного SQL осуществляется захват сессий SQL*Loader. В дальнейшем этот код будет использован при синхронизации PDB приложений с корневым контейнером приложений. Поэтому необходимо, например, избегать указания полного имени файла при создании табличных пространств. При синхронизации будет попытка создания такого же табличного пространства с тем же самым именем файла и синхронизация окончится ошибкой. Посмотреть захваченный SQL код можно в представлении DBA_APP_STATEMENTS:
Если на момент инсталляции приложения уже существовали другие (не корневые) PDB приложений в этом контейнере, то для того чтобы общие метаданные и данные приложения стали видны в таких PDB, их нужно синхронизировать командой ALTER PLUGGABLE DATABASE APPLICATION . SYNC, подключившись к такой PDB. То же самое относится и к вновь создаваемым PDB при отсутствии в этом корневом контейнере специальной предзаполненной PDB, создаваемой с опцией AS SEED, либо если такая SEED PDB не была предварительно синхронизирована с корневым контейнером. При наличии SEED PDB, другие PDB в этом контейнере приложений создаются как ее клоны. Встроенное приложение APP$CON можно синхронизировать, как и любое другое.
Изменить приложение можно операцией Upgrade либо Patch. Разница между операциями состоит в наборе допустимых SQL команд в корневом контейнере после выполнения команды ALTER PLUGGABLE DATABASE APPLICATION . BEGIN [UPGRADE | PATCH]. Крупные изменения обычно оформляются как операция Upgrade, а более мелкие как Patch. При этом в рамках операции Patch недопустимы, например, разрушающие команды (DROP . ). Обе операции меняют версию приложения в корневом контейнере приложений.
После начала изменения приложения и до команды ALTER PLUGGABLE DATABASE APPLICATION . END [UPGRADE | PATCH] производится такой же захват SQL кода, как и при инсталляции приложения.
Для обеспечения работоспособности существующих некорневых PDB автоматически создается клон корневого контейнера со старой версией приложения.
Если при выполнении SQL кода явно не была начата ни одна из операций Upgrade либо Patch, то считается, что изменение относится к встроенному приложению APP$CON и оформляется как операция Patch для него. Может появиться искушение не создавать свои приложения, а воспользоваться тем, что есть по умолчанию. Но не всегда это может быть возможным — в APP$CON может быть захвачен код, который имеет смысл только для корневого контейнера приложений и оканчивающийся ошибкой в обычной PDB приложений. В примере ниже в APP$CON захвачена операция, которая может быть успешно выполнена (если только в этой PDB уже не был создан локальный пользователь с таким же именем) при синхронизации в любой PDB. Результатом синхронизации будет создание пользователя toys_test в синхронизируемой PDB.
Для того чтобы остальные (в том числе и SEED) PDB могли использовать новую версию приложения, их необходимо синхронизировать с корневым контейнером приложений.
Кроме пользователей, ролей, профилей и многие другие объекты базы данных, в том числе таблицы и PL/SQL код, могут рассматриваться как общие для данного контейнера приложений и создаваться в рамках операций Install, Upgrade и Patch с разными значениями атрибута SHARING:
- METADATA — метаданные такого объекта рассматриваются как общие (принадлежат корневому контейнеру приложений), но данные будут уникальны для каждой PDB (размещаются в них). Это является поведением по умолчанию.
- DATA — метаданные и данные такого объекта рассматриваются как общие и размещаются в корневом контейнере приложений, а остальные PDB видят эти метаданные и данные по ссылке.
- EXTENDED DATA — метаданные и часть данных принадлежат корневому контейнеру приложений, но каждая из PDB может иметь и собственную порцию данных.
- NONE — объект не используется совместно.
Мне такая архитектурная конструкция стала напоминать объектную модель таких языков программирования, как Java. Осталось только допустить (сейчас запрещено) вложенность корневых контейнеров приложений друг в друга с возможностью наследования и переопределения метаданных, то мы фактически получили бы иерархию классов не ограниченную как сейчас тремя уровнями. Объекты, разделяемые в режиме DATA, могли бы выступать в качестве в качестве статических элементов класса, METADATA как объектные элементы и т.д.
Еще одним вариантом использования контейнерных баз данных, является возможность расщепить большую таблицу на фрагменты и каждый фрагмент обрабатывать независимо от других в своей PDB. А с появлением возможности, которую предоставляют proxy PDB, то и разнести нагрузку по обработке данных на разные контейнерные СУБД, находящихся на разных хостах. Перемещение же PDB с одной контейнерной базы данных в другую контейнерную базу данных тоже, в свою очередь, значительно упростилось и теперь может быть осуществлено практически без остановки обслуживания пользователей в этой PDB. И, если раньше для создания запроса по набору PDB требовалось использование специального синтаксиса с конструкцией CONTAINERS(), то теперь с помощью контейнерных карт можно это сделать, не меняя исходный код приложения.
Практические примеры
Теперь обо всем по порядку.
Имеем 2 контейнерные базы данных: CDB1 и CDB2. Подключаемся к ним в разных сессиях и настраиваем SQLPROMPT для удобства:
В CDB1 создаем корневой контейнер приложений app_root:
Инсталлируем приложение app1:
При создании табличного пространства используем OMF, иначе мы не сможем выполнить захваченный код в PDB приложений при синхронизации.
У таблиц будут общими только метаданные, а данные в каждой PDB будут свои.
Настраиваем возможность создания запросов к таблицам через контейнерную карту. Свойство таблицы containers_default позволяет её использовать во фразе CONTAINERS(table_name) запроса. А свойство container_map позволяет делать отсечку секций (фактически целиком PDB) при выполнении запроса основываясь на ключе секционирования использованном во фразе WHERE. Например WHERE region_id = 2.
Вспомогательную процедуру load_sales, при помощи которой будем заполнять таблицу sales случайными тестовыми данными, тоже сделаем частью приложения:
Заканчиваем инсталляцию приложения:
Создаем таблицу контейнерной карты, имена секций в ней должны совпадать с именами PDB приложений, а данные в каждой PDB будут соответствовать своему региону в соответствии с ключом секционирования region_id:
Создадим шаблонную PDB (SEED), на основе которой будут создаваться другие PDB и синхронизируем ее с корневым контейнером приложений:
Теперь можно создать PDB содержащие данные. Они будут создаваться как клон app_root$seed и поэтому их синхронизация с корневым контейнером не понадобится:
Заполним данными наши таблицы и соберем статику по ним. Статистика по общим объектам собирается по месту нахождения данных.
Устанавливаем таблицу maptable в качестве контейнерной карты:
Теперь запрос, сделанный из корневого контейнера приложений, должен вернуть данные из обеих PDB без использования фразы CONTAINERS, а таблицы содержать псевдостолбец CON_ID. Проверяем:
Создадим консолидированный отчет и посмотрим план выполнения такого запроса:
Теперь посмотрим, как можно перемещать наши PDB в другие контейнерные базы данных, не изменяя код приложения, создающий консолидированную отчетность. Это может понадобиться, например, при исчерпании ресурсов на данном сервере или для того, чтобы сбалансировать нагрузку по серверам. Переносить будем PDB asia в CDB2. Для этого нам понадобиться сделать клон корневого контейнера app_root на CDB2, а на CDB1 создать proxy PDB, которая будет прозрачно для приложения перенаправлять запросы на другую базу данных через Database Link. Обе базы данных должны работать в режиме локального UNDO и архивирования журнальных файлов.
Склонируем корневой контейнер приложений app_root с CDB1 на CDB2 под именем app_rr:
На CDB1 создадим proxy PDB для перенаправления запросов на CDB2:
Для перемещения PDB мы должны дать на базе источнике привилегию SYSOPER пользователю, через которого работает Database Link на приемнике:
Готовим базу данных приемник:
Перемещаем PDB asia на CDB2:
В данный момент PDB asia у нас присутствует на обеих CDB. На CDB1 она открыта на чтение/запись, а на CDB2 она закрыта:
Но при первом открытии на чтение/запись PDB asia в CDB2, на старом месте в CDB1 её автоматически закроют и удалят. При необходимости, можно было бы воспользоваться режимом AVAILABILITY MAX, чтобы не обрывать существующие сессии пользователей к перемещаемой PDB.
Осталось проверить что наш запрос создания консолидированной отчетности по-прежнему работает:
Установила Oracle 12c и вошла под пользователем system . Хочу создать своего пользователя natali и возникло несколько вопросов:
- Какие права минимум нужно выдать новому пользователю?
- Что такое табличное пространство Oracle?
- Нужно ли создавать отдельно табличное пространство для пользователя или можно использовать пространство USER ?
В версии 12c введена мултиарендная (multitenant) арxитектура БД, состоящая из двх частей: контейнера (CDB) и (одной или нескольких) подключаемых БД (PDB). Кратко об их отличаях в этом ответе.
Содавать новых пользователей, а также вообще что-либо менять в CDB не следует. Часто можно найти решение со скрытым параметром _ORACLE_SCRIPT=true для обхода ограничений при создании пользователей в CDB. Его применение строго не рекомендуется.
Поэтому, для подключения с системной учётной записью надо обязательно указывать имя службы конкретной PDB, например:
При установке БД былo создано стандартное табличное пространство USERS, которое будет использоваться для всех вновь создавемых пользователей БД. Создавать новое табличное пространство нет никакой необходимости.
Для выделения минимума привилегий новому пользователю, следует учесть, что через поисковики часто можно найти ранее широко используемые роли CONNECT и RESOURCE , но их уже в версии 10g больше не рекомендовали к применению:
Note:
Customers should discontinue using the CONNECT and RESOURCE roles, as they will be deprecated in future Oracle Database releases.
Исходя из вышеизложенного, дайте самый минимум прав и привилегий напрямую, и далее выделяйте их по мере необходимости. То есть, сделайте следующее:
Версия Oracle database 12c внесла существенное новшество в 30-ти летний продукт. Теперь внутренний системный "словарь" экземпляра разделён на части, что позволяет создавать "облегчённые" базы данных с усечённым "пользовательским словарём". Такие базы могут быть легко "извлечены" из одной контейнерной базы и "подключены" в другую, как одно целое. При этом такое существенное изменение в продукте остаётся полностью прозрачным для правильно написанного приложения.
Также в новой версии наконец-то появилась достойная альтернатива ужасному Cloud Control - облегчённый простой и эффективный Enterprise Manager Express.
В предлагаемой заметке я привожу пример установки Оракла 12c, создания контейнерной и подключаемой баз и включения Enterprise Manager Express.
Прежде чем мы продолжим, я хотел бы привести строки из Евангелия:
. == От Иоанна святое благовествование == .
=== Глава 10, Стих 9 ===
1 Истинно, истинно говорю вам: кто не дверью входит во двор овчий, но
перелазит инуде, тот вор и разбойник;
2 а входящий дверью есть пастырь овцам.
3 Ему придверник отворяет, и овцы слушаются голоса его, и он зовет своих овец
по имени и выводит их.
4 И когда выведет своих овец, идет перед ними; а овцы за ним идут, потому что
знают голос его.
5 За чужим же не идут, но бегут от него, потому что не знают чужого голоса.
6 Сию притчу сказал им Иисус; но они не поняли, что такое Он говорил им.
7 Итак, опять Иисус сказал им: истинно, истинно говорю вам, что Я дверь овцам.
8 Все, сколько их ни приходило предо Мною, суть воры и разбойники; но овцы не
послушали их.
9 Я есмь дверь: кто войдет Мною, тот спасется, и войдет, и выйдет, и пажить
найдет.
Лично для вас благая весть - Единородный Сын Божий Иисус Христос любит вас, Он взошёл на крест за ваши грехи, был распят и на третий день воскрес, сел одесную Бога и открыл нам дорогу в Царствие Небесное.
Словно радуга после дождя, всегда приходящая вместе с теплыми лучами солнца и пением птиц, Слово Божие всегда прямо перед нами - только повернись лицом к свету, открой Библию, прочти чудесные строки - и вот Он, Спаситель Иисус Христос, прямо перед вами. Господь всегда приходит к нам в светлых видениях и мыслях, явно принося милость благодать и прощение для тех, кто захочет услышать.
Но как же часто мы с вами как будто специально отворачиваемся от Приходящего к нам дверями нашей души пастыря и блуждаем по тёмным закоулкам наших сердец, ища мнимых благ, утешающих самолюбие и жадность, но губящих душу! И ведь слышим же голос Иисуса, зовущий нас за Ним, и ведь знает сердце наше голос этот - и так и рвётся к Нему навстречу. Ан нет, вновь опускаем очи наши долу и смотрим пристально под ноги, надеясь найти золотой слиток. Но всё чаще находим лишь объедки после чьего-то грешного застолья . А ведь всего-то и нужно, что поднять глаза, дать душе рвануть вверх - именно там спасение, пажить с достатком, необходимым для спокойной счастливой независтливой жизни, и вход и выход .
Покайтесь, примите Иисуса как вашего Спасителя, ибо наступают последние времена и время близко - стоит Судья у ворот.
Пожалуйста, в своих каждодневных трудах, какими бы занятыми вы себе ни казались - находите время для Бога, Его заповедей и Библии.
На главной странице этого сайта вы найдете программу для чтения Библии в командной строке - буду очень рад если программа окажется полезной. Пожалуйста, читайте Библию, на экране или в печатном виде - вы будете искренне удивлены как много там сказано лично про вас и ваши обстоятельства.
Вернёмся к нашим техническим деталям.
В 12-том Оракле данные пользователя и приложений должны храниться исключительно в "подключаемых" базах. "Контейнерная" база содержит только "системную" часть словаря, "корневую" системную базу и "начальную" базу-пустышку. Возможно создание "монолитной" базы "по старинке", так же как это делалось в 10 и 11 версиях, но от этого способа надо как можно скорее отказываться.
Установка ОС и Oracle 12c в silent режиме
Как всегда, всё начинается с операционной системы. Установим Oracle Linux Server release 5.8 в виде виртуальной или физической машины. Я использую Virtual Box и просто "клонирую" уже имеющуюся систему:
Если вы используете виртуализацию - создайте "snapshot" сейчас, до начала установки Oracle. Это позволит "откатить" машину назад в случае неудачи.
Во время установки, запуска и тестирования базы наблюдайте за производительностью вашей ОС. В моём случае я наблюдаю за самим "хостом", а не за "виртуалкой":
Таким образом я также отслеживаю температуру процессора, материнской платы и видео карты. Данные могут быть неточны - сравните с показаниями в BIOS.
Теперь распакуем архив файла поставки:
Подготовка к установке
Запуск программы установки
Я предпочитаю устанавливать Oracle Database в "молчаливом" режиме, который позволяет мне чётко видеть происходящее, обнаруживать ошибки, легко повторять установку на нескольких машинах (узлах кластера?) и продлевать срок службы мышки.
Действия после установки
После установки, как указано в лог файле, мы запустим скрипт от имени суперпользователя:
Теперь остались мелочи - добавить вновь установленный Оракл в маршрут поиска файлов и проверить переменные среды пользователя:
Настройка и запуск Network Listener
После того, как все двоичные файлы и библиотеки Оракла были установлены на предыдущем этапе, нам надо начать с конфигурирования и запуска сетевых процессов. Для подготовки listener файла мы будем использовать "помощника сетевой конфигурации":
Создание "Контейнерной" базы данных, без схем пользователя
Для создания пустой "контейнерной базы" я использую тот же самый Database Configuration Assistant.
Новая база данных создана - но мы не будем хранить в ней никаких данных конечных пользователей. Эта база, в соответствии с её именем, является просто контейнером для хранения "системных" компонентов - и они используются совместно всеми "подключенными" базами, устраняя ненужное дублирование данных и уменьшая число рекурсивных системных вызовов.
Тем не менее, контейнерная база регистрируется листенером и мы можем подключаться к ней, как показано ниже. Но прежде всего нам надо было создать тот самый "системный" каталог в нашей пустой контейнерной базе - обычно это делалось скриптами, так же это делается и сейчас. Одно "НО" - в нашей "пустой" контейнерной базе CDB уже сейчас имеются две "подключаемые" базы - "root" и "seed". В каждой из этих PDB наш DBCA, используя скрипт, должен был создать индивидуальную "пользовательскую" часть (копию) каталога, и при этом в самом "контейнере" CDB - одну общую для всех "системную" часть разделённого каталога Oracle.
Начало "прелестей" виртуализации . таким образом, скрипт "catcon.pl" даёт нам возможность запускать любой, даже пользовательский, SQL скрипт во всех pluggable databases за один раз, экономя время.
Пора проверить результат нашей установки - можем ли мы подключиться к вновь созданной контейнерной базе CDB? Заметьте - в выводе listener мы не видим никаких строк с типом протокола "RAW". Это важно - смотрите следующий фрагмент ниже.
Уже очевидно, что мы сможем подключиться к базе CDB через SQL*Plus. Но как же графики и картинки? Тут ситуация на удивление улучшилась значительно!
Мы можем "создать" внутри самой базы необходимые компоненты так, что Enterprise Manager Express (используя встроенную XML DB - в нашем примере выше это "CDBXDB") будет "обслуживать" только эту базу, не требуя никаких дополнительных систем типа Cloud Control. К тому же, сама функциональность Enterprise Manager Express изначально ориентирована на разработчиков и администраторов баз данных, что очень радует и упрощает работу. С самого начала, главная страница Enterprise Manager Express предоставляет нам в одном месте всю необходимую для работы информацию. Видно что EM Express разрабатывал специалист по базам данных, а не разработчик Java приложений.
Повторюсь, EM Express не является J2EE приложением, не требует Weblogic или других локальных контейнеров. Это простое и изящное продолжение DB Control'a, с добавкой дополнительных возможностей, взятых из SQL Active Reports. И всё это находится непосредственно внутри базы, использует только XML DB и не имеет внешних зависимостей.
Откроем вебброузер и зайдём на адрес "http://db12c.localdomain:8080/em". Убедитесь что дополнения вроде NoScript, Adblock and FlashBlock не блокируют веб сайт. Зайдите под именем пользователя "sys/oracle", отметив при этом опцию "as sysdba".
Теперь зайдите на страницу "Performance/Performance Hub" - это удачно дополняет функциональность "SQL Active Report". Будьте внимательны и проверьте лицензирование вашего сервера - EM Express использует различные EM Packs, которые должны иметь отдельную лицензию.
Отключить EM Express также просто:
На мой взгляд, EM Express - одно из самых удачных нововведений Oracle 12c.
Создание "Подключаемой" базы из существующего "образца"
Все наши действия до этого момента были бесполезны для конечного пользователя. Несмотря на обилие уже выданных команд, приложениям всё ещё негде хранить данные. Настало время создать подключаемую базу (pluggable database). Существует несколько способов создания PDB - мы будем создавать базу путём копирования структуры существующего образца ("seed") - этот образец был создан заодно с CDB.
Из имени контейнера видно, что мы подключены к "корню" "CDB$ROOT" контейнерной базы CDB, в которой (видно из "cdb_pdbs") имеется "образец" "PDB$SEED" - именно из него мы и будем создавать новую клиентскую базу.
Проверим появилась ли новая база в нашем "общем" системном словаре Oracle:
В процессе создания PDB появляются записи в alert log, здесь я пересоздаю PDB повторно:
Подключение к новой PDB
Как я уже говорил, сетевые службы стали особенно важны - подключиться к PDB можно только через её service (в нашем случае "pdb1").
Обратите внимание - запуск "контейнерного" экземпляра CDB открывает саму CDB но оставляет все подключаемые PDB в смонтированном, но неоткрытом состоянии. Открыть все PDB за один раз можно командой "alter pluggable database all open" - но она сработает только если вы подключены к "CDB$ROOT". Все вновь созданные PDB находятся в состоянии "mount".
Также с введением PDB появляется новый принцип - каждое приложение должно иметь собственную подключаемую базу. Это позволяет избежать неприятностей с совпадающими именами объектов, синонимов и прочее. Кроме того логическая "изоляция" данных каждого приложения упрощает поддержку и миграцию.
Итак, мы открыли вновь созданную подключаемую базу PDB1 - но всё это было сделано при подключении к контейнерной базе CDB. Теперь подключимся (наконец-то!) к самой PDB1.
Заметим, что "контейнерная" база CDB предоставляет "общий" tablespace UNDO для всех "подключаемых" баз PDB, но при этом каждая из PDB имеет свою собственную "копию" SYSTEM, SYSAUX и TEMP.
Также запомним что "локальный" администратор подключаемой базы PDB не может подсоединиться к "корню" контейнерной базы CDB:
Работа с подключаемой базой
Проверить параметры одной PDB можно так.
Кроме того, пользователь "SYS" из контейнерной базы CDB, но подключенный к PDB, не сможет изменить "системную" часть "разделённого" словаря Oracle. Этот же пользователь сможет выполнить эту же самую операцию, но подключившись к контейнеру "CDB$ROOT". Это сделано в качестве попытки защитить ДБА от самих себя?
Возьмём на заметку, что единственно возможный способ установления сессии, имеющей PDB в качестве начального контейнера - это указание имени сетевой службы (service) в строке подключения. Сие означает, что текущий контейнер можно изменять в ходе работы с уже подключенной сессией.
Также "разделённый" словарь Oracle означает что при обновлении (upgrade) Oracle Home нам понадобится запускать скрипт только на CDB. Множество мелких PDB не потребуют обновлений, поскольку PDB могут "видеть" (но не изменять!) уже обновлённые объекты из "общей" части системного словаря CDB. Внутренние механизмы под названием "metadata link" и "object link" позволяют всем PDB видеть "общую" часть стандартных объектов, поставляемых Ораклом в составе "database dictionary".
Демонстрируя смену текущего контейнера, попытаюсь ввести некие ограничения на объём дискового пространства, потребляемого одной PDB. Предположим, что моя PDB должна "укладываться" со всеми её tablespaces (users, sys and temp) в рамки 2 Гб и при этом не потреблять более 0.8 Гб "общего" TEMP tablespace, предоставляемого CDB.
Что бы это значило?
Ну что, дорогой читатель, с вас хватило "новинок виртуализации"? :-) Если всё ещё нет - подумайте о PDB на платформе RAC .
В общем, похоже нас ожидают интересные времена и Oracle не даёт нам скучать :-)
Читайте также: