Pluggable database oracle что это

Обновлено: 02.07.2024

Клонирование подключаемой базы данных XEPDB1 может понадобиться для самых различных целей. Например, для создания среды разработки и тестирования.

Cоздание клона подключаемой БД XEPDB1.

Необходимо подключиться к CDB под пользователем sys:

Проверить список имеющихся подключаемых баз данных (PDB) и их статусы:

Можно увидеть, что подключаемая база данных XEPDB1 открыта и работает в режиме чтения и записи данных (Open mode – read write). Для клонирования надо сперва перевести PDB XEPDB1 в режим монтирования (mount), а потом только чтения (read only).

В режиме mount нельзя вносить изменения в объекты и база становится доступной только для администраторов.

Еще раз проверяется статус подключаемых баз данных. Результат показывает, что PDB XEPDB1 теперь работает в режиме монтирования (mounted):

Затем PDB XEPDB1 (далее XEPDB1) переводится в режим только чтения (read only). Режим read only позволяет совершать запрос, но не позволяет совершать изменения пользователям.

Просматривается список PDB и их статусы:

Теперь, когда XEPDB1 в режиме только чтения, можно приступать к созданию непосредственно клона этой базы данных. Клон XEPDB1 будет называться MSU. Для создания клона PDB будет использована команда create pluggable database. Если create pluggable database запустить без параметра file_name_convert или create_file_dest, то можно получить ошибку ORA-65016:

Для того, чтобы данная ошибка не возникала, необходимо указать директорию, где будут созданы файлы для новой PDB MSU. Директорию для файлов клона PDB можно указать с помощью одного из двух параметров в команде create pluggable database: file_name_convert или create_file_dest. При указании параметра file_name_convert система сама создает поддиректорию MSU в директории /opt/oracle/oradata/XE:

Для параметра create_file_dest необходимо предварительно создать директорию операционной системы, иначе можно получить ошибку:

Проверяются имеющиеся PDB и их статусы :

Как можно увидеть, появилась новая PDB MSU, находящаяся в режиме монтирования. Основная PDB XEPDB1 находится в режиме read only. Теперь необходимо перевести эти две PDB в режим чтения и записи. Запускается команда, которая открывает все базы данных в режим чтения и записи, кроме шаблонного PDB (PDB$SEED).

Далее проверяется состояние баз данных:

Как видно, PDB XEPDB1 и MSU теперь находятся в режиме чтения и записи. Последним шагом будет сохранение состояния read write для PDB MSU. Параметр save state позволяет вернуть PDB MSU в текущее состояние (read write) после перезагрузки корневой БД – CDB. Другими словами, после перезагрузки CDB будет осуществлен автоматический запуск PDB MSU также как и XEPDB1.

Для создания второго клона подключаемой БД XEPDB1 выполняются следующие действия.

Подключение к CDB под пользователем sys:

Просматриваются имеющиеся подключаемые базы данных и их статусы:

Выполняется перевод PDB XEPDB1 в режим монтирования и проверяется, что она теперь работает в другом режиме (mounted).

Затем XEPDB1 переводится в режим read only и снова просматриваются состояние PDB.

Создается еще один клон базы XEPDB1, который будет называться TTU.

Просматриваются все имеющиеся подключаемые БД и видно, что новая PDB TTU создана и работает в режиме mounted:

Все PDB кроме PDB$SEED переводятся в режим чтения и записи и проверяются их статусы:

Сохраняется состояние нового клона для будущего автоматического запуска после перезагрузки CDB:

На этом завершается описание создания двух новых клонов Pluggable Database XEPDB1 в Oracle Database 18c Express Edition.

На момент написания статьи официальный выпуск новой версии 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 - это многозадачные базы данных. Они также стали известны как подключаемые базы данных. Если вы не слышали о облаке, вы должны были жить под скалой последние несколько лет. c в 12c означает облако.

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

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

Опция Multitenant для Oracle 12c лицензируется. Как обычно, обратитесь к представителю отдела продаж Oracle за расходами. Опять же, убедитесь, что вы знаете о возврате инвестиций, которые эта функция может принести вам.

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

База данных контейнеров (CDB): Основная база данных, содержащая несколько подключаемых модулей базы данных. Многие операции могут выполняться на уровне контейнера для снижения затрат на управление. База данных создается либо как CDB, либо CDB.

Pluggable Database (PDB): Набор объектов схемы, объектов и объектов, которые могут быть подключены и отсоединены от базы данных контейнера. PDB представляется OracleNet и конечным пользователям как сама база данных, но фактически управляется внутри контейнера, который может иметь много PDB.

База данных семян (Seed PDB): PDB по умолчанию, который система использует в качестве шаблона для быстрого предоставления других пользовательских PDB. Внутри это называется PDB $ SEED.

Параметр Multitenant позволяет выполнить следующее:

Высокая плотность консолидации: Многие базы данных могут совместно использовать память и фоновые процессы.

Предоставление: База данных может быть отключена от одной среды и подключена к другой или клонирована командами SQL всего за несколько секунд. Их можно даже подключить к операционным системам и наборам микросхем.

Управление несколькими базами данных как один: Вы можете выполнять такие задачи, как резервное копирование и исправление в основной базе данных контейнера вместо отдельных подключаемых баз данных.

Управление ресурсами: Функция Oracle Resource Manager может работать на уровне подключаемых баз данных для управления конкуренцией ресурсов между базами данных в вашей среде.

Еще одна вещь, о которой стоит упомянуть, заключается в том, что подключаемая база данных полностью совместима с не-CDB. Фактически, у Oracle есть что-то, что он называет гарантией совместимости с PDB / non-CDB, , в котором говорится, что все, что вы делали бы в не-CDB, также будет работать в PDB. Эта гарантия совместимости важна, когда речь заходит о сертификации таких продуктов, как сторонние продукты-производители, для работы в многопользовательской архитектуре.

Как создать среду многопользовательской базы данных в Oracle 12c

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

Следуя расширенному пути создания базы данных, первое, что вы можете заметить, это флажок для базы данных Create As Container на шаге 4 из 13.

Вы также можете выбрать количество созданных PDB в это время. Вы также можете создать пустую базу данных контейнера без подключаемых баз данных в начале. Остальные этапы почти такие же, как при создании не-CDB.

Как запускать и останавливать подключаемые базы данных в Oracle 12c

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

Первое, что нужно помнить, состоит в том, что, поскольку CDB поддерживает экземпляр, для которого все PDB совместно используют, этот экземпляр должен быть открыт и открыт для людей, чтобы иметь возможность подключаться к PDB. Запуск и остановка CDB не отличается от не-CDB.

Следующее, что нужно помнить, это то, что при запуске CDB все связанные с ним PDB остаются в состоянии MOUNT, а это значит, что по умолчанию они не открываются CDB. К сожалению, 12cR1 не предлагает вариант изменить это поведение.

Однако 12c действительно обеспечивает запуск нового типа триггера, который будет срабатывать, если он обнаружит открытие CDB и затем откроет определенные PDB. Дополнительную информацию по настройке см. В документации Oracle.

После запуска и открытия CDB вы можете открыть любые соответствующие PDB следующим образом:

Чтобы закрыть PDB, вы можете по существу сделать противоположное предыдущим командам:

Вы можете использовать представление словаря данных V $ PDBS для получения информации о готовности PDB.

Самым крупным нововведением недавно вышедшего Oracle 12c безусловно является Multitenant Architecture. Сам Oracle преподносит эту возможность в основном как средство консолидации и снижения расходов.

Суть технологии состоит в возможности запустить несколько независимых баз (pluggable database, PDB) в рамках одного инстанса (container database, CDB). Каждая база имеет свой набор схем и табличных пространств, но при этом у них общая SGA и один набор серверных процессов. Есть возможность клонировать pluggable database, как в рамках одного контейнера, так и между контейнерами. Вот эту возможность и будем использовать для создания копий тестовых баз и экономии ресурсов.

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

В документации на команду CREATE PLUGGABLE DATABASE, в разделе клонирования есть упоминание об опции SNAPSHOT COPY. Судя по описанию, при создании клона с опцией SNAPSHOT COPY, файлы данных клонируемой базы копироваться не будут. Для них будут
созданы copy on write снапшоты и место на диске будут занимать только измененные блоки клонированной базы. Создание клонов со снапшотами возможно либо на ACFS, либо на специализированных NAS .

Эксперимент проводился в среде Oracle Virtualbox 4.2.14. Я не буду подробно описывать инсталляцию, она хорошо освещена в документации, буду останавливаться только на важных моментах.

Инсталляция

Ставим Oracle linux 6.4 c апдейтами, зависимости для oracle и поддержку ASM:

конфигурируем ASM и создаем ASM disk:

Инсталлируем Oracle Database 12c Release 1 Grid Infrastructure (12.1.0.1.0) for Linux x86-64 в режиме singl node. В discovery path -> /dev/oracleasm/disks.
Командами asmcmd или с помощью asmca создаем disk group (DATA) volume (DATAVOL) и ASM cluster filesystem c точкой монтирования (/data). Из под root монтируем ACFS и убеждаемся что все хорошо:

Подключаемся к инстансу ASM и меняем режим совместимости:

В результате получаем базу-контейнер и с seed database (модельная база для создания pluggable database).
Проверяем что все получилось:

Работа с клонами

Создаем каталог на ACFS /data/oradata, и меняем владельца на oracle. Меняем параметр db_create_file_dest на /data/oradata. Cоздаем клон который будет изображать тестовую базу:

На ACFS должен появиться каталог с буквенно-цифровым именем (случайным), содержащий наш PDB:

PDB после создания или рестарта контейнера нужно открывать:

Имитируем создание тестовой базы — создадим tablespace test размером 2G:

Убеждаемся что файл данных есть и размер его 2 гигабайта:

Ради чего все это затевалось

Мы имеем тестовую базу большого объема и хотим протестировать особо крупное изменение, затрагивающее структуру таблиц и требующее для проверки всех данных.
Клонируем тестовую базу в режиме snapshot:

И смотрим что произошло на файловой системе:

Файлы данных всех табличных пространств кроме TEMP это ссылки на ACFS снапшот, и место на диске они не занимают. Узнать сколько реально занял снапшот можно так:

Чего и добивались — 286МB против более 3GB

Естественно, если активно начать изменять блоки клона со снапшотами, занимаемое им место вырастет.

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

Убеждаемся что место освободилось:

Результат

В результате нам удалось сэкономить время и ресурсы. И не только дисковые, напомню, что все базы PDB используют один комплект процессов и одну SGA.

PS. Статья не претендует на полное описание Oracle Multitenant Architecture, рассмотрен лишь частный случай применительно к конкретной задаче.

Обычно DBA Oracle является sqlplus, процесс входа в систему выглядит следующим образом:

Имя созданного экземпляра: oracs133

В Oracle 12c была добавлена концепция сменной базы данных, PDB, позволяющая Один контейнер базы данных (CDB) содержит несколько подключаемых баз данных (PDB) 。

CDB называется Database Container, китайский переводится в контейнер базы данных, PDB называется Pluggable Database, вы можете подключить базу данных.

До ORACLE 12C экземпляры и базы данных находились в отношении «один к одному» или «многие к одному» (RAC): то есть экземпляр мог быть связан только с одной базой данных, и база данных могла загружаться несколькими экземплярами. Отношения между экземпляром и базой данных не могут быть однозначными. После ввода ORACLE 12C экземпляр и база данных могут иметь отношение один ко многим.

Ниже приводится официальный документ об отношениях между CDB и PDB.

(1) Запустить базу данных

Запуск CDB

12c pass " sqlplus / as sysdba "Логин для подключения CDB Сейчас подключен root container 。

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

Возможны следующие варианты запуска:

NOMOUNT: только начать Экземпляр базы данных Читайте в это время Файл параметров ；
MOUNT: найти и открыть в соответствии с расположением контрольного файла в файле параметров Контрольный файл , Прочитайте различную информацию о параметрах в управляющем файле, такую как местоположение файла данных и файла журнала, но не открывайте файл данных в это время;
ОТКРЫТО: открыто Файлы данных, файлы журналов Подождите и выполните серию проверок, эти проверки используются для восстановления данных (по умолчанию, если никакие параметры не добавляются, он переходит в состояние ОТКРЫТО)
OPEN также имеет две опции: OPEN READ ONLY (открыть базу данных в режиме только для чтения), OPEN READ WRITE (это по умолчанию, открыть базу данных в режиме чтения-записи ）
FORCE: запустить базу данных. Разница с опцией OPEN заключается в том, что для запуска используется опция FORCE. Если текущая база данных была запущена, об ошибке не будет сообщено, но автоматически ОТКЛЮЧИТСЯ ABORT текущей базы данных, а затем начнется снова, что можно понимать как RESTART
RESTRICT:
PFILE：

Запуск PDB

Конкретный процесс заключается в следующем:

PDB $ SEED создается системой, следующий ORACS133PDB1 создается пользователем, дефолт После запуска CDB PDB Автоматически начинает состояние монтирования Вместо OPEN , Так нужно Вручную открыть состояние 。

(2) Закройте базу данных

Чтобы продолжить вышеуказанную операцию, в настоящее время в pdb1, если вы хотите выйти из Oracle, вам сначала нужно закрыть PDB1, а затем закрыть базу данных.

После выбора CDB выполните отключение базы данных.

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

Заключительные шаги также могут быть разбиты:

Закройте файл данных, файл журнала и т. Д. Последовательно ( close ), контрольный файл ( dismount ) и, наконец, закройте экземпляр ( shutdown ）。

Вы также можете закрыть базу данных за один шаг:

Прежде чем закрыть CDB, PDB не закрывается, поэтому эта операция также закроет PDB.

2. Несколько параметров и значение ОТКЛЮЧЕНИЯ

После выхода из базы данных состояние подключения самих данных не изменилось.

НОРМАЛЬНОЕ ОТКЛЮЧЕНИЕ: метод выключения по умолчанию: а) не разрешает новые подключения к базе данных; б) может быть закрыт только после отключения всех соединений, что менее эффективно

SHUTDOWN IMMIDIATE : Общий способ завершения работы: а) не разрешается создавать новые подключения; б) созданные подключения, если есть незавершенные операторы SQL, ждут их завершения, если не сразу отключены; в. Откат всех незафиксированных транзакций

ОТКЛЮЧЕНИЕ ТРАНЗАКЦИОННОГО: Очень низкое использование

ОТКЛЮЧЕНИЕ АБОРТА: а) незафиксированные транзакции не откатываются; б) завершают все операции SQL; в) все соединения отключаются. База данных быстро закрывается, но в следующий раз, когда ее необходимо восстановить, она запускается медленно, и данные сегмента отката и файла данных могут быть несовместимыми.

Читайте также: