Содержание
это рабочий материал по переводу оригинальной англоязычной статьи. Что то переведено. что то в процессе
- (1) Как структурирована статья
- Для тех кому не нужно детальное описание
- -- Кто хочет полного понимания
- (2) Про Oracle Multitenant
- -- Стремление достигнуть максимальной плотности консолидации
- --- Стандартизация уменьшает операционные расходы
- --- Стандартизация - дальнейшие возможности по сокращению операционных и капитальных расходов
- -- Настройка (обеспечение) баз данных
- -- Патчевание и обновление версий Oracle СУБД
- (3) Высокоуровневое описание мультиарендности
- (4) Статические аспекты мультиарендной архитектуры - горизонтально партицированный словарь данных и подключаемость:
- -- Таблицы - окончательная логическая реальность
- -- Не CDB архитектурно - монолитный словарь данных
- -- Горизонтально партицированный словарь данных в мультиарендной архитектуре
- --- Общийе подходы
- --- практическое определение PDB и root
- --- Обзор внутренней кухни
- (5) Операции с дочерними БД - unplug/plug, clone, create, drop
- -- Unplug/plug from machine to machine
- -- Unplug/plug across different operating systems, chipsets, or endiannesses
- -- Unplug/plug for patching the Oracle version
- -- Unplug/plug for responding to SLA changes
- -- Клонирование PDB
- --- Клонирование PDB используя полную копию
- --- Клонирование PDB используя снапшот
- --- Клонирование PDB из неподключенной PDB
- --- Удалённое клонирование через репликацию GoldenGate как альтернатива операциям unplug/plug
- --- Синтаксис SQL запросов для клонирования
- -- Создание PDB
- --- Синтаксис SQL запросов для создания PDB
- -- Удаление PDB
- --- Синтаксис SQL запросов для удаления PDB
- -- Почему важно проводить типовые операции (create PDB, clone PDB, drop PDB, and unplug/plug) посредством SQL запросов
- -- Отключение и подключение, и клонирование PDB для CDBs, защищённых Data Guard
- (6) Как воспринимать (внедрять) не CDB как PDB
- -- Прямое внедрение 12.1 non-CDB как PDB
- -- Внедрение (принятия понимание) контента non-CDB
- (7) Динамические аспекты мультиарендной архитектуры экземпляр, пользователи и сессии:
- -- Обшее про пользователей, роли и разрешения
- --- Локальные пользователи и локальные роли
- --- Общие пользователи и общие роли
- --- Общая выдача привелегий и общие роли
- --- Пользовательские общие пользователи и общие роли
- -- Сервисы и сессии
- -- Смена контейнера текущей сессии для установленных сессий
- -- SGA логически виртуализирован
- -- Представления словаря данных и производительности
- (8) Сравнение выбора CDB и выбора PDB
- -- Выбор - использовать вообще только CDB
- --- Сессии СУБД Oracle и особенности платформ
- --- The spfile, control files, and password file
- --- Data Guard, RMAN backup, redo, and undo
- --- Character set
- --- CDB-wide initialization parameters and database properties
- --- Отчёты AWR
- -- Вариант, когда возможна кастомизация для каждой PDB
- --- Восстановление на заданную точку времени отдельной PDB
- --- Оперативный бэкап RMAN для PDB
- --- alter system flush Shared_Pool
- --- Инициализационные параметры и свойства базы данных, устанавливаемые в PDB
- --- Ошибка ORA-65040
- (9) Управление ресурсами внутри CDB и между PDB
- -- вычисление ресурсов для уровня CDB в версии 12.1
- -- Разделяемая и ограничивающая модели
- -- Как план уровня CDB управляет сессиями, CPU, процессами Oracle parallel server и файловым вводом/выводом
- -- особенности PDB-to-RAC-instance
- (10) Отдельная PDB в CDB или не CDB
- (11) Итог
- (12) Приложение A:
- -- Обработка мультиарендной архитектуры в библиотеке документации по СУБД Oracle
----------------------------------------------------------------
1 Как структурирована статья
-- Для тех кому не нужно детальное описание
Вам нужно прочитать следующие разделы:
Customer challenges addressed by Oracle Multitenant on page 5
High-level description of Oracle Multitenant on page 9
Summary on page 48
It would help to skim these sections:
How to adopt a non-CDB as a PDB on page 29
Per CDB choices versus per PDB choices on page 39
Within-CDB, between-PDBs, resource management on page 43
Lone-PDB in CDB versus non-CDB on page 47
-- Кто хочет полного понимания
Тщательно прочитать всё от начала до конца
-- Описание секций
Про Oracle Multitenant (потребительские задачи) описывает стрелление собрать много БД на одной платформе для максимизации возврата вложений,
конфигурирования БД и обновления большого количества БД сразу
Общее описание Oracle Multitenant описывает терминологию новой архитектуры, контейнеры мультиарендной БД (именуемые CDB) и подключаемые БД (PDB), и
описывает общие моменты в функциональности и увязку с ожидапниями потребителя
Статические аспекты мультиарендной архитектуры ... Кратко - виртуализация уровня БД включает супер - БД (контейнер) и дочерние подключаемые БД
Операции с дочерними БД очевидно
We are now ready to describe very simply, in How to adopt a non-CDB as a PDB on page 29,
how a pre-12.1 database can be adopted as a PDB.
Динамические аспекты ... показывают отличия между общими и локальными пользователями и как создавать связанную с PDB сессию. А также рассматриваются
как SGA, оперативные журналы, и табличные пространства отмены логически (не физически) виртуализируются путём пометки их принадлежности к той или иной
системе
Per CDB choices versus per PDB choices в целом говорит о возможностях сохранённой как PDB базы старых версий
Within-CDB, between-PDBs, resource management говорит об управлении ресурсами между PDB внутри CDB
Lone-PDB in CDB versus non-CDB рассматривает одиночную PDB в контейнере CDB как выделенную БД в архитектуре более старых версий СУБД
--------------------------------------------------------------
2 Про Oracle Multitenant
-- Стремление достигнуть максимальной плотности консолидации
--- Стандартизация уменьшает операционные расходы
--- Стандартизация - дальнейшие возможности по сокращению операционных и капитальных расходов
-- Настройка (обеспечение) баз данных
-- Патчевание и обновление версий Oracle СУБД
Customer challenges addressed by Oracle Multitenant
These days, it is fairly common to find hundreds, or thousands, of databases scattered over
almost as many machines, within customer sites of reasonable to large size. The associated
expense has driven initiatives to bring lots of databases together, in other words to consolidate,
to reduce these costs. Over the previous decades, database administrators have been spending
more time than they want to, provisioning databases, patching the Oracle version of each of
very many databases, planning, setting up, and managing backup and disaster recovery
regimes, and otherwise managing each database as its own individual ongoing exercise.
Striving to achieve maximum consolidation density
Standardization is intrinsically beneficial there is, quite simply, less to understand. It further
allows many databases that conform to a particular standard to be consolidated onto a single
platform that implements that standard.
Standardization reduces operating expense
The high cost of ownership to an organization that has very many databases is exacerbated by
variation between these databases. The most obvious variables are the type of hardware and
operating system, the choice of options, and the choice of the Oracle Database software
version characterized by the finest granularity of one-off patch. Other variables, such as
how the scheduled backup regime is conducted, and how disaster recovery is catered for, play
their part.
Many customers have discovered that the first step to managing complexity is to host as many
databases as possible on each of as few as possible hardware platforms. Operating system
virtualization seems at first to be an attractive expedient to allow the autonomy of
management of each individual database that was enjoyed when each was on its own
platform. However, it is exactly by minimizing the variation between databases that is allowed
by operating system virtualization, that management cost savings are to be found. Therefore,
customers who consolidate many databases onto few machines have realized that
operating system virtualization is a solution to a problem that they dont have and prefer,
therefore, to use the native operating system without virtualization and, further, to deploy as
few as possible Oracle Home installations; in other words, they standardize on hardware type, on
operating system version and patch-level, and on the particular configurations of
Oracle Database that they support.
Standardization brings further opportunities to reduce operating expense and capital expense
Customers who have come this far in pursuit of consolidation have realized that
consolidation density is limited by the fact that each additional database brings a noticeable
incremental requirement for memory and CPU, because each has its own SGA and set of
background processes multiplied, of course, when Oracle Real Application Clusters is
deployed. At this point, they realize that the important metric is not the density of databases
that a platform can support, but rather the density of application backends that it can support.
We will define the term application backend to mean the set of artifacts that implement, within a
database, the persistence mechanism for a particular application. Inevitably, there exists a
mechanical scheme, for every application, to install its application backend. This might
consist entirely of SQL*Plus scripts, of a combination of these and Data Pump import files
and commands, or of purpose-built client programs that issue the appropriate
June 2013
page 5
Oracle Multitenant
_________________________________________________________________________________________________________________
SQL statements. But a mechanical scheme will surely exist. We use the term artifact to denote
the effect of any change to the database made by an application backends installation scheme.
The most obvious examples are objects listed in DBA_Objetcs like tables, indexes, views,
PL/SQL packages, and so on. But some artifacts, like users, roles, and tablespaces are not
objects in this sense. Nor are the effects of granting privileges or roles to users or roles. And
nor is data in application tables used as application metadata.
Historically, each application backend has been housed in its own dedicated database.
However, many distinct application backends can be installed into the same database by
running the installation scheme for each in turn. This approach is usually referred to as
schema-based consolidation, and we shall use this term in this paper2.Customers have shown that
schema-based consolidation supports a noticeably bigger consolidation density, measured in
application backends per platform, than is possible when each application backend is in its
own database hereinafter the dedicated database model. The consolidation density depends on
properties of the application backends, like the size of database memory that it needs and the
throughput that it must support. Moreover, by drastically reducing the number of databases,
significant savings in management costs follow.
However, schema-based consolidation has some notorious disadvantages.
Name collision might prevent schema-based consolidation. Some application backends are
implemented entirely within a single schema. In such cases, the name of the schema can
usually be chosen freely, needing only to be specified in a central client-side configuration
file. Such application backends can be usually be trivially installed in the same database (but
even so, there are some potential problems, as will be seen below). It is this use case, of
course, that gave rise to the term schema-based consolidation.
Other application backends are implemented in several schemas, which implies
cross-schema references and therefore a dependency on the specific schema names that the
design has adopted. Of course, it is possible that the same schema names will be used in
different application backends. But the name of a schema must be unique within the
database as a whole, and so application backends with colliding schema names cannot be
installed in the same database unless at least one of them is changed. Such a change would
usually be considered to be prohibitively expensive.
Moreover, the names of other phenomena must also be unique within the database as a
whole. Examples are roles, directories, editions, public synonyms, public database links, and
tablespaces. Even considering application backends, each of which is implemented in a
single schema, the names of these other phenomena might collide and prevent them from
being installed in the same database.
Schema-based consolidation brings weak security. The person who installs a particular application
backend needs to authenticate as a database user with powerful privileges like Create User,
Alter User, and Drop User. This person could then make changes to any other application
backend in the same database, and could therefore read, or change, its confidential data.
Moreover, a poorly designed application backend whose implementation uses more than
one schema might rely on system privileges like Select Any Table, Delete Any Table, and so on.
In such a case, for example, a SQL injection vulnerability might allow a run-time user of
one application backend to read, or to change, another application backends data.
2.
June 2013
We shall see later that schema-based consolidation is one kind of within-database consolidation, and we shall
contrast this with the kind that the multitenant architecture brings: PDB-based consolidation.
page 6
Oracle Multitenant
_________________________________________________________________________________________________________________
An application backend might require that certain privileges are granted to public, for
example Execute on Sys.Utl_File. On the other hand, another might specifically prohibit this
privilege being granted to public. These two application backends could not coexist in the
same database.
Per application backend point-in-time recovery is prohibitively difficult. Point-in-time recovery is
usually called for when an error in application code, introduced by an application patch, is
discovered to have caused irreparable data corruption. Therefore, it is the single application
backend, and not the whole database, that needs to be recovered to the time just before the
bad application patch was applied. In a fortunate case, tablespace point-in-time recovery
might be sufficient. But this can be difficult when the corrupt data spans several
tablespaces. It is difficult, too, if an administrator dropped one or more mutually
referencing tables by mistake.
Resource management between application backends is difficult. It relies on the humanly imposed
convention that one or several specific services will be used to start the sessions that access
a particular application backend, and that no service will be used for more than one
application backend. In other words, the distinction between each different application
backend is known only by the human administrator; the database has no knowledge of
these distinctions.
Patching the Oracle version for a single application backend is not possible. If one application backend
needs a patch to the Oracle Database software version, this cannot be done without
affecting all the other application backends.The only alternative is to use Data Pump to
move the application backend that needs the patch to a different database where it has
already been applied. However, database artifacts of some kinds, for example XML
schemas, cannot be moved using Data Pump.
Cloning a single application backend is difficult. Data Pump is the only option.
Notwithstanding the significant drawbacks of schema-based consolidation, many customers
have adopted the practice and have demonstrated significant increase in return on investment.
The reason, of course, is that the savings in capital expenditure brought by the high
consolidation density, and the savings in operating expenditure brought by having fewer
databases to manage, dominate the costs brought by the disadvantages described above.
Provisioning of databases
Database administrators have, over the years, needed to devote significant time, on most
typical working days, to creating new databases, to moving existing databases from machine
to machine, and to creating maximally current clones of existing databases for various
purposes of development, testing, and problem diagnosis. We shall denote this class of chore
by the term provisioning.
Patching and upgrading the Oracle Database software version
While not as frequent a chore as provisioning, applying one-off patches, bundled patches,
patch set updates (critical or ordinary) and patch sets to existing databases, and upgrading
them from a point-one release to a point-two release, or a point-two release to the next
point-one release, is stressful and time-consuming. We shall refer to this chore as patching the
Oracle version. We shall make frequent use of this term; its too long-winded always to
distinguish between patching and upgrading, or to call out that we mean the version of the
June 2013
page 7
Oracle Multitenant
_________________________________________________________________________________________________________________
Oracle Database software, including the executable binaries and the Oracle system within the
database, rather than the version of the application backend.
--------------------------------------------------------------
3 Высокоуровневое описание мультиарендности
High-level description of Oracle Multitenant
Oracle Database 12c supports a new architecture that lets you have many sub databases
inside a single super database. From now on, we shall use the official terminology. The
super database is the multitenant container database abbreviated as CDB; and the sub
database is the pluggable database abbreviated as PDB. In other words, the new architecture
lets you have many PDBs inside a single CDB. (In 12.1, the maximum number is 252.) We
shall refer to the new architecture as the multitenant architecture.
We clearly now need a term for the old kind of database, the only kind of database that was
supported through Oracle Database 11g. We shall call this a non-CDB; and we shall refer to the
old architecture as the non-CDB architecture.
Oracle Database 12c Release 1 supports both the new multitenant architecture and the old
non-CDB architecture. In other words, you can certainly upgrade a pre-12.1 database, which
necessarily is a non-CDB, to a 12.1 non-CDB and continue to operate it as such. But, if you
choose, you can adopt the 12.1 non-CDB into a CDB as a PDB3.
From the point of view of the client connecting via Oracle Net, the PDB is the database. A
PDB is fully compatible with a non-CDB. We shall refer to this from now on as the
PDB/non-CDB compatibility guarantee4. In other words, the installation scheme for an
application backend that ran without error against a non-CDB will run, with no change, and
without error, in a PDB and will produce the same result. And the run-time behavior of client
code that connects to the PDB holding the application backend will be identical to that of
client code that connected to the non-CDB holding this application backend. It is intended
that a PDB be used to hold a single application backend. In this way, the PDB provides a
direct, declarative means to contain an application backend so that the Oracle system knows
explicitly which artifacts belong to which application backend. In contrast, when
schema-based consolidation is used within a non-CDB, the Oracle system has no information
about where the various artifacts belong. We shall see that each foreground process sees, at a
moment, just a single PDB; indeed, in the simplest usage model, a database user, defined
within a PDB, is able to create only sessions that see only that PDB and only, therefore, the
artifacts that belong to a single application backend5.
Recognition of the PDB/non-CDB compatibility guarantee allows very many questions to be
answered by assertion: if the answer were not yes, then the principle would not have been
honored. Tests, conducted by Oracle Corporation engineers throughout the whole of the 12.1
development cycle have proved that client code connecting with Oracle Net cannot
distinguish between a PDB and a non-CDB. Here are some examples:
Can two PDBs in same CDB each have a user called Scott? Yes, because two non-CDBs can each
have a user called Scott. By extension, two PDBs in same CDB can each have: a role with the
same name; a directory with the same name; an edition with the same name; a public
synonym with the same name; a public database link with the same name; and a tablespace
3. 4. A caveat is made about the PDB/non-CDB compatibility guarantee in the section The ORA-65040 error on
page 42.
5.
June 2013
The details are explained in How to adopt a non-CDB as a PDB on page 29.
This is explained in detail in The dynamic aspects of the multitenant architecture: the Oracle instance, users, and sessions
on page 31.
page 9
Oracle Multitenant
_________________________________________________________________________________________________________________
with the same name. Moreover, in one PDB you can grant Execute on Sys.Utl_File to public
while in another you make no such grant a grant to public in a PDB is seen only in that
PDB. Similarly, an Any privilege can be exercised only in the PDB where it was granted.
In other words, a PDB defines a global namespace, just as a non-CDB does. And it contains
the effects of privileges, just as a non-CDB does.
Can you create a database link between two PDBs? Yes, because you can do that between two
non-CDBs. A database link is created by executing a SQL statement. Therefore, such a
statement must produce the same result in a PDB as it does in a non-CDB. By extension,
you can create a database link from a PDB to a non-CDB, or from a non-CDB to a PDB
and these can cross a difference in Oracle Database software version in the same way as
is supported between two non-CDBs.
Can you set up GoldenGate replication between two PDBs? Yes and by extension, you can set it
up between a PDB and a non-CDB, crossing a difference in Oracle Database software
version. (The functionality is brought by the first Oracle GoldenGate version that supports
12.16.)
From the point of view of the operating system, it is the CDB that is the database. Each
RAC instance opens the CDB as a whole, and each SGA can contain data blocks and library
cache structures like child cursors from each of the PDBs contained in the CDB7. (This is an
indirect way of stating that, of course, the multitenant architecture is fully interoperable with
Oracle Real Application Clusters.)
We see that the multitenant architecture supports, therefore, a new model for within-database
consolidation: PDB-based consolidation.
The population of the SGA in the PDB-based consolidation model is directly comparable to
its population in the schema-based consolidation model. There, too, each RAC instance
opens the non-CDB, and each SGA can contain data blocks and library cache structures from
each of the application backends consolidated into the non-CDB. It follows therefore that it
is the CDB that is at a particular Oracle Database patchset level. The PDBs it contains inherit
this, just as do the schemas in a non-CDB. It is no more meaningful to ask if two PDBs in the
same CDB can be at different Oracle Database patchset levels than it is to ask if the Scott and
Blake schemas can be at different Oracle Database patchset levels in the same non-CDB.
A suitably privileged database user allows a person who knows its password to start a session
that can see information from the data dictionary views and the performance views across all
the PDBs that the CDB contains8. In other words, a single system image is available via SQL
and therefore via tools like SQL Developer and Enterprise Manager. In fact, these tools
are extended to expose all the new functionality brought by the multitenant architecture.
6. 7. We shall see in The SGA is logically virtualized on page 34 that each PDB can have a different Open_Mode in
each RAC instance.
8.
June 2013
Engineering work was required because, in the multitenant architecture, each redo log entries is annotated with
the identifier of the container where it originated. See Data Guard, RMAN backup, redo, and undo on page 39.
The full understanding of this depends on notions explained later, notably the root (in The static aspects of the
multitenant architecture: the horizontally partitioned data dictionary and pluggability on page 12), the common user (in Th
dynamic aspects of the multitenant architecture: the Oracle instance, users, and sessions on page 31), and container_dat
views
(in Data dictionary views and performance views on page 36).
page 10
Oracle Multitenant
_________________________________________________________________________________________________________________
The multitenant architecture extends Resource Manager to allow a CDB-level plan to manage
the competition of resources between the PDBs.
Oracle Active Data Guard is conducted at CDB-level, as is the regime of scheduled
RMAN backup. Point-in-time-recovery is supported at PDB-level.
Finally, you can unplug a PDB from one CDB and plug it into another CDB. It is this, of
course, that gives the pluggable database its name. You can also create a new PDB as a clone
of an existing one. When the underlying filesystem supports thin provisioning, many
terabytes can be cloned almost instantaneously. All the operations on PDBs as opaque entities
creating a brand new one, unplugging one, plugging one in, cloning one, and dropping one
are exposed as SQL statements. You request cloning using thin provisioning simply by
using the keyword snapshot in the SQL command. Unplug/plug is implemented by a natural
extension of the transportable tablespace technology, and is possible because of
within-database virtualization that characterizes the multitenant architecture. Unplug/plug is
even supported across a difference in the Oracle Database software version9.
The new multitenant architecture is available in Standard Edition, in Standard Edition One,
and in Enterprise Edition. However, without licensing the Oracle Multitenant option, you are
limited to a maximum of one PDB10. The significance of this model is discussed in
Lone-PDB in CDB versus non-CDB on page 47.
--------------------------------------------------------------
4 Статические аспекты мультиарендной архитектуры -
горизонтально партицированный словарь данных и подключаемость:
-- Таблицы - окончательная логическая реальность
-- Не CDB архитектурно - монолитный словарь данных
-- Горизонтально партицированный словарь данных в мультиарендной архитектуре
--- Общийе подходы
--- практическое определение PDB и root
--- Обзор внутренней кухни
The static aspects of the multitenant architecture:
the horizontally partitioned data dictionary and pluggability
Customers who have implemented schema-based consolidation have, in effect, made an
attempt to implement within-database virtualization without any intrinsic support from
Oracle Database. This section attributes the difficulties of this approach to the historical
architecture of the data dictionary. It then introduces the basic notion of the
multitenant architectures intrinsic virtualization: the horizontally partitioned data dictionary.
Tables: the ultimate logical reality
A quiesced Oracle Database consists only of its files. Besides the bootstrap files (the control
file, spfile, and so on), the overwhelming bulk is the files that implement the tablespaces.
Tablespaces, in turn, contain only tables and various structures to speed up access and to
ensure their recoverability. It is the tables, of course, that are a tablespaces raison detre. Other
database artifacts, of all kinds, like constraints, views, PL/SQL objects, and so on, are
ultimately represented as rows in tables. Tables hold only three kinds of data: metadata that
describes the Oracle system, metadata that describes customer-created application backends,
and quota-consuming data in an application backends tables.
The non-CDB architectures monolithic data dictionary
Through 11.2, both the metadata that describes the Oracle system, and the metadata that
describes customer-created application backends, are represented in a single set of tables,
known collectively as the data dictionary. The tables are famously implicitly maintained by the
executables that implement the Oracle instance as side-effects of DDL statements.
Customers are not allowed to do direct insert, update, and delete to these tables, and their
structure is not documented so that the information they represent must be queried via the
data dictionary views. Nevertheless, customers have come to know the names of these tables
(Obj$, Tab$, Col$, and so on) and to understand their significance. These data dictionary tables
are stored in dedicated tablespaces, most notably the System tablespace. Figure 1 shows the full
content of a freshly created non-CDB, before any customer artifacts have been created.
non-CDB
System tablespace
Obj$
Tab$
...
Col$
Figure 1 A pristine non-CDB
The first effect of installing an application backend into a non-CDB is that rows are inserted
into the data dictionary tables to represent its metadata. Because the ultimate purpose of an
application backend is to be the applications persistence mechanism, this metadata will, of
June 2013
page 12
Oracle Multitenant
_________________________________________________________________________________________________________________
course, include the description of application tables. Following conventional best practice,
these tables will be stored on dedicated application data tablespaces. The application tables
will soon contain quota-consuming data, so that total set of tables that define the non-CDB
will be as shown in Figure 2.
non-CDB
System tablespace
Obj$
Tab$
Application_Data tablespace
...
Col$
Departments
Employees
...
Jobs
Figure 2 A non-CDB after installing application backend artifacts
In Figure 2, and in Figure 3 and Figure 4 in the next section, we use red to denote
customer-created artifacts (both metadata rows and quota-consuming data rows) and black to
denote the artifacts that represent the Oracle system (only metadata rows).
Of course, the namespaces for global artifacts like users, roles, editions, tablespaces, and the
like are defined by the unique indexes on tables like User$, Edition$, TS$, and so on.
Correspondingly, global artifacts like the grants made to users and to roles, including the public
role, are represented in the SysAuth$ and ObjAuth$ tables. This immediately explains the name
collisions that characterize the attempt to install two or more application backends into the
same non-CDB, and the security problems that follow.
Figure 2 lets us understand, too, the leap forward that was made by the second generation
Data Pump by using transportable tablespaces. The first generation Data Pump used
entirely slow-by-slow11 construction, at export time, and replay, at import time, of SQL
both DDL statements and DML statements. The second generation replaced the use of
DML statements by treating the set of tablespaces that hold the applications
quota-consuming data (shown on the right, and entirely in red, in the diagram) as
self-contained units holding the complete account of the table data and the indexes on them
removing the need for using DML statements. Notably, at import time, a transportable
tablespace is plugged in using only metadata operations that, therefore, are very fast.
Figure 2 also lets us understand the reason that there was, pre-12.1, no third generation
Data Pump: because each data dictionary table contains both customer metadata and
Oracle system metadata, the only recourse for moving this part of the application backend is
still slow-by-slow DDL statements.
In summary, it is the non-CDB architectures monolithic data dictionary that causes the
difficulty of schema-based consolidation, the poor security of the resulting regime, and the
11. I attribute the phrase slow-by-slow to Oracles Tom Kyte. You can find it in frequent use in AskTom and in his
articles for Oracle Magazine.
June 2013
page 13
Oracle Multitenant
_________________________________________________________________________________________________________________
limits to the mobility of an application backend. To put this another way, the
non-CDB architectures data dictionary is not virtualized.
The multitenant architectures horizontally partitioned data dictionary
The solution, then, is obvious: the multitenant architectures data dictionary is virtualized.
The approach in broad outline
The textbook approach to virtualization is to identify every phenomenon that implements a
system and to tag it with the identifier of whom it belongs to. The simplest way, conceptually,
to have done this would have been to add a new column to every data dictionary table to
denote the application backend that it describes and to use a special value for the rows that
describe the Oracle system. But this approach would not have addressed the mobility of the
application backend. Therefore, the logical tagging scheme was implemented physically, by
horizontally partitioning the data dictionary. (Dont confuse the implementation of this with
the implementation of Oracle Partitioning, as this feature is exposed for customers to use.
The implementation is quite different. The data dictionary is partitioned in the ordinary,
abstract, sense of the term.) Figure 3 shows the scheme for a CDB holding a single application
backend.
CDB
Application metadata and data
System tablespace for application metadata
Obj$
Tab$
...
Col$
Application_Data tablespace
Departments
Employees
...
Jobs
Oracle system metadata
System tablespace for Oracle system metadata
Obj$
Tab$
...
Col$
Figure 3 The multitenant architecture introduces the horizontally partitioned data dictionary
June 2013
page 14
Oracle Multitenant
_________________________________________________________________________________________________________________
The lower half, as we choose to show it in this paper, holds the metadata for the
Oracle system and nothing else. And the upper half holds the metadata for the
application backend and nothing else. In other words, each data dictionary table now
occurs twice, once for the Oracle system, and once for the application backend. Conceptually,
every query against a data dictionary table is now a union between the two occurrences of
that table.
Notice that each set of data dictionary tables is in its own tablespace(s) and therefore in its
own datafiles. The paths of the datafiles must, of course, be unique within the filesystem. But
the names of the tablespaces, and the segments they contain, need to be unique only within
the data dictionary table in either the upper or the lower partition. It is natural, therefore
to use the same names for the data dictionary tables, and the same names for the tablespaces
that contain them, in both partitions.This point is explored in the next section.
The practical definition of PDB and root
The set of tablespaces, and therefore the set of datafiles, that implement the data dictionary
tables that hold the metadata for the Oracle system is called the root. (Its name is CDB$Root.)
And the set of tablespaces (and therefore their datafiles) that implement the data dictionary
tables that hold the metadata for the application backend, together with the set of tablespaces
that hold the application backends quota-consuming data (and therefore the datafiles for all
of these), is the PDB. The PDB is therefore a full database while the root is just a
meta-database. Because the data dictionary is now virtualized, the same CDB can, of course,
contain many PDBs, where each is, ultimately, its own set of self-contained datafiles.
This is shown in Figure 4.
CDB
PDBs
(application metadata and data)
PDB_1
PDB_2
PDB_3
...
PDB_251
PDB_252
root
(Oracle system metadata)
Figure 4 In the CDB architecture, up to 252 PDBs plug into the root
Significantly, then, each PDB defines a private namespace for all the phenomena, like users,
roles, public synonyms, and so on, that in a non-CDB must be unique within the whole
database. Each PDB in a particular CDB can have a user called Scott. It follows, then, that the
result of granting privileges and roles, represented in the SysAuth$ and ObjAuth$
data dictionary tables are also contained within a PDB.
Though the root differs significantly from a PDB in that it never holds quota-consuming data,
there is a strong similarity between these CDB components because each has a
data dictionary and can be the focus of a foreground process. We therefore use the term
June 2013
page 15
Oracle Multitenant
_________________________________________________________________________________________________________________
container as the superclass term for the root or a PDB. A foreground process, and therefore a
session, at every moment of its lifetime, has a uniquely defined current container.
The PDB is so-called because it can be unplugged from the root of one CDB and plugged into
the root of another CDB. The big black arrow in Figure 4 denotes this. Of course, the roots
metadata describes each PDB that is plugged into it. On unplug, the metadata for the
unplugged PDB is deleted; and on plugging in, metadata is created to describe the plugged-in
PDB. This is a natural extension of the pre-12.1 transportable tablespace technology. We can
see, therefore, that unplug and plug of a PDB can be considered to be third generation
Data Pump: both the quota-consuming data and the metadata that jointly completely
represent an application backend can be moved as an opaque, self-contained unit, removing
the need for constructing and replaying slow-by-slow DDL statements.
A sketch of the internals of the approach
You might wonder how data dictionary queries are implemented but if you dont, you can
skip this section. We dont refer again to this explanation, or rely on it for understanding what
follows.
All queries are implemented, ultimately, by bringing blocks into the buffer cache. A block
must therefore be addressed, and part of its address is the number of the file where it is
stored. The multitenant architecture uses a relative scheme for datafile numbering based on
the identity of sessions current container. In normal operation, the current container is a
PDB, and therefore the session has access only to blocks from that PDBs datafiles. This
relative datafile numbering scheme is implemented at a low level in the layered modules that
implement Oracle Database: the sessions PDB identifier is passed via a side-channel to the
low-level module; and the various higher-level APIs through which the SQL and PL/SQL
compilation and execution subsystems communicate downwards to the data layer are
unchanged with respect to the non-CDB architecture. This means, in turn, that very large
amounts of the code that implements Oracle Database the whole of SQL (including,
therefore the optimizer), the whole of PL/SQL, and everything (like, for example, the
Scheduler) that builds upon these needed no change in 12.1 to accommodate the new
multitenant architecture. It was therefore relatively easy to honor the PDB/non-CDB
compatibility guarantee.
When a data dictionary query, issued in the context of a PDB, needs to access the rows that
describe the Oracle system, the current container switches to the root and then switches back.
The mechanism that signals this need, and that brings efficiency, is indicated by the dotted
line arrow in Figure 3 from a row in the PDBs Obj$ table to a row in the roots Obj$ table. An
Oracle-supplied object is represented fully in the root by the closure of all the various detail
tables that refer directly or indirectly to a row in the roots Obj$ table. And it is represented
sparsely in a PDB by just one row in its Obj$ that points to the corresponding row in the root.
--------------------------------------------------------------
5 Операции с дочерними БД - unplug/plug, clone, create, drop
-- Unplug/plug from machine to machine
-- Unplug/plug across different operating systems, chipsets, or endiannesses
-- Unplug/plug for patching the Oracle version
-- Unplug/plug for responding to SLA changes
-- Клонирование PDB
--- Клонирование PDB используя полную копию
--- Клонирование PDB используя снапшот
--- Клонирование PDB из неподключенной PDB
--- Удалённое клонирование через репликацию GoldenGate как альтернатива операциям unplug/plug
--- Синтаксис SQL запросов для клонирования
-- Создание PDB
--- Синтаксис SQL запросов для создания PDB
-- Удаление PDB
--- Синтаксис SQL запросов для удаления PDB
-- Почему важно проводить типовые операции (create PDB, clone PDB, drop PDB, and unplug/plug) посредством SQL запросов
-- Отключение и подключение, и клонирование PDB для CDBs, защищённых Data Guard
The operations on PDBs as entities:
unplug/plug, clone, create, drop
We next see how these operations, implemented in the context of the
multitenant architecture, bring new paradigms for provisioning and patching the Oracle
version.
Unplug/plug from machine to machine
Figure 5 shows PDB_1 plugged in to the root of CDB_1 running on machine 1. By design,
PDB_1 holds exactly one application backend. The aim now is to move this application
backend from machine 1 to machine 2.
PDB_1
root root
CDB_1 (machine 1) CDB_2 (machine 2)
Figure 5 Unplug/plug between two machines: PDB_1 starts in CDB_1
While a PDB is contained in a CDB, the CDB holds metadata for it, like the name it has in
this CDB and the paths to its datafiles. (Some of this is held in the root, and some is held in the
CDBs control file. This distinction is unimportant for the present discussion.) On unplug,
this metadata is written to an external manifest that accompanies the PDBs datafiles. Unplug
is implemented as a single SQL statement, illustrated in Code_1.
-- Code_1
-- The PDB must be closed before unplugging it.
alter pluggable database PDB_1
unplug into '/u01/app/oracle/oradata/.../pdb_1.xml'
The semantics are give the name of the PDB, say that you want to unplug it, and specify
the path for the external manifest.
Correspondingly, plugging in is implemented as a single SQL statement, illustrated in Code_2.
(The SQL statement for plugging in an unplugged PDB is a variant of the
create pluggable database statement. The other variants are clone PDB and creating a brand-new
PDB. The examples shown in Code_2, Code_3 on page 25, Code_4 on page 25, Code_6 on page 25,
June 2013
page 17
Oracle Multitenant
_________________________________________________________________________________________________________________
and Code_7 on page 26 assume that Oracle-Managed Files is turned on.)
-- Code_2
-- The PDB must be opened after plugging it in.
create pluggable database PDB_2
using '/u01/app/oracle/oradata/.../pdb_1.xml'
path_prefix = '/u01/app/oracle/oradata/pdb_2_Dir'
The path_prefix clause is optional. It may be specified only with the create pluggable database
SQL statement. It may not be changed for an existing PDB. It affects the outcome of the
create directory SQL statement when it is issued from a PDB that was created using this clause.
The string supplied in create directorys path clause is appended to the string supplied in
create pluggable databases path_prefix clause to form the actual path that the new directory object
will denote. This is an important measure for controlling between-PDB isolation.
Code_2 produces the result shown in Figure 6.
PDB_1
root root
CDB_1 (machine 1) CDB_2 (machine 2)
Figure 6 Unplug/plug between two machines: PDB_1 finishes up in CDB_2
The semantics are say that you want a new PDB, say that it is created by plugging in an
unplugged PDB by specifying the path for the external manifest, give the plugged in PDB a
name in its new CDB, and ensure that any directory objects created within the PDB are
constrained to the specified subtree in the filesystem that the CDB uses.
Unplug/plug across different operating systems, chipsets, or endiannesses
Similar considerations apply for cross-platform unplug/plug as apply for the cross-platform
use of transportable tablespaces. When a customer-created tablespace is converted from one
endianness to the other, using the RMAN convert command, it is only block headers that are
changed (because these are encoded in an endianness-sensitive way). Data in columns in
customer-created tables is left untouched. Most of these (we hope) will use primitive scalar
datatypes like varchar2 and number and these are represented, endianness-insensitively, in
network byte order. On the other hand (we hope, again) when columns of datatype raw or blob
are used, then these will be used to hold data (like, for example, .pdf or .jpg files) that is
consumed only by client-side code that knows how to interpret it. However, customers might
encode data in an endianness-sensitive way, and in such a case it is their responsibility to know
where this has been done and to apply their own conversion processing after a transportable
tablespace containing such data has been plugged in across an endianness difference.
June 2013
page 18
Oracle Multitenant
_________________________________________________________________________________________________________________
The discussion is made more complicated because an unplugged PDB contains
data dictionary tables, and some of the columns in these encode information in an
endianness-sensitive way. There is no supported way to handle the conversion of such
columns automatically. This means, quite simply, that an unplugged PDB cannot be moved
across an endianness difference.
Meanwhile (while the data dictionary remains endianness-sensitive), if the functional goal is
cross-endianness unplug/plug, then the only viable approach is to use Data Pump to migrate
the content into a new, empty PDB in the target CDB. If transportable tablespaces are used,
then they must be processed using RMAN convert. If the data volume is small, it may be faster
to use classic Data Pump without transportable tablespaces.
Moreover, moving on from the endianness discussion, PL/SQL native compilation might
have been used; and if it has, then a particular data dictionary table will hold machine code
that is sensitive to the chipset of the platform where it was compiled. If an unplugged PDB
holding such machine code is plugged in to a CDB running on a platform with a different
chipset from the platform where the CDB from which the PDB was unplugged was running,
then it is no longer viable. In this case, the remedy is simple: all natively compiled PL/SQL
units in the incoming PDB must be recompiled before the PDB can be made available for
general use.
Unplug/plug for patching the Oracle version
The multitenant architecture supports plugging a PDB into a CDB whose Oracle Database
software version differs from that of the CDB from which it was unplugged. (While 12.1.0.1
is the only available 12.1 version, this capability, of course, cannot be demonstrated.)
The least aggressive patches change only the Oracle binaries in other words, by definition,
this kind of patch makes no changes inside the datafiles. This implies that when the source
and destination CDBs differ by this kind of patch, the incoming PDB needs no change
whatsoever; it is sufficient (and of course necessary) only to check, using information in the
PDBs manifest, that the Oracle Database software version difference is of this kind.
More aggressive patches make changes to the definition of the Oracle system in the
data dictionary. (These typically make changes to the Oracle binaries as well.) But to deserve
the name patch rather than upgrade, these data dictionary changes usually cause no knock-on
invalidation. For example, if an Oracle-supplied package body is recompiled using a new
implementation to fix a bug, then the package spec remains valid, and so, therefore, do all the
objects in the closure of its dependants. With the advent of fine-grained dependency tracking
in Oracle Database 11g, even if an Oracle-supplied package spec is changed by adding a new
subprogram that doesnt overload an existing subprogram name, then there is no knock-on
invalidation. When this kind of patch is applied to a non-CDB, then no customer-created
artifact is changed. This implies that, even for this kind of patch, the incoming PDB needs no
change12. We shall see, presently, that even for a patch that does cause some knock-on
invalidation, the compensating work needed in the PDB will be small.
June 2013
page 19
Oracle Multitenant
_________________________________________________________________________________________________________________
To exploit the new unplug/plug paradigm for patching the Oracle version most effectively,
the source and destination CDBs should share a filesystem so that the PDBs datafiles can
remain in place. This is shown in Figure 7.
PDB_1
before
after
root root
CDB_1 (version 1) CDB_2 (version 2)
Figure 7 Unplug/plug between two CDBs across an Oracle Database software version difference
while the datafiles remain in place on a shared filesystem
Because the unplug/plug operations affect only the metadata in the root that describes the
PDB, they are very fast. The total time to close a PDB, unplug it from the source CDB, plug
it into the destination CDB, and open it, when the datafiles remain in place, is measured in
seconds on a typical machine when there is no difference in the Oracle Database software
version. This implies that the time will be the same when the difference is due only to changes
in the Oracle binaries, and only marginally more when the difference is due to data dictionary
changes that dont cause invalidation of any customer-created artifacts. Even for patches that
do cause some invalidation among customer-created artifacts, fine-grained dependency
tracking will minimize the amount of recompilation that needs to be done in the incoming
PDB. Notice that our self-imposed compatibility rules guarantee that changes made by
patching the Oracle version (or by upgrading it) will never leave a customer-created object,
that was valid before these changes, in an irrevocably invalid state. Recompilation will always
return these cascadingly-invalidated objects to validity.
12. Because of the fact that the implementation uses an Obj$ row in the PDB to point to the corresponding Obj$
row in the root, as described in A sketch of the internals of the approach on page 16, and because the row in the
PDB encodes a signature of its partner row in the root, then the PDB row needs to be re-computed. Further,
the Dependency$ table in the PDB is fully populated. Its semantic content, for Oracle system artifacts, is the
same as its partner row in the root, but it uses local values for the object numbers for the dependency parent
and dependant. It records the details of fine-grained dependencies, like the timestamp of the compilation of
the dependency parent, and an encoding of what attributes of this the dependant depends upon. You can guess
that a PDB cannot express its dependencies on objects in the root using the object numbers there because these
can be different in different CDBs. The connection between the Obj$ row in the PDB and its partner in the root
implements the mapping and without this, then fast unplug/plug wouldnt work. Therefore, following
plugging in the PDB, when source and destination CDBs differ by this kind of patch, it will be necessary also
to recompute the details of fine-grained dependencies, and, possibly, some rows in the PDBs Dependency$
table. This is a very quick operation.
June 2013
page 20
Oracle Multitenant
_________________________________________________________________________________________________________________
Upgrades to the Oracle Database software version are allowed to make drastic data dictionary
changes with knock-on effects for customer-created artifacts. (We use upgrade to denote going
from a point-one release to a point-two release like 12.1 to 12.2, or from a point-two release to the next
point-one release, like 12.2 to 13.1.) When this kind of upgrade is applied to a non-CDB, then
the scripts attend first to the Oracle system and then to the customer-created artifacts. This
implies that, when source and destination CDBs differ by this kind of upgrade, the incoming
PDB needs to suffer the same scripted changes that, in a non-CDB, follow the scripted
changes to the Oracle system. The time needed to make the required changes in the incoming
PDB is, therefore, inevitably less than that taken, in a non-CDB, to do exactly this as well as
first making the required changes to the Oracle system.
In other words, when an application backend is hosted in a PDB, the outage time for the
application caused by patching the Oracle version, using the unplug/plug approach, is always
less than that for applying the same patch to a non-CDB and sometimes it can be
measured in seconds, even for patches that cause limited cascading invalidation within the
PDB. When the processing inside the incoming PDB is guaranteed not to cause invalidation
among the customer-created artifacts, then this might be done implicitly. Otherwise, the user
will be notified that an Oracle-supplied script must be run.
Notice that, further, the cost of setting up the patched destination CDB is highly amortized.
It is paid once, but benefits patching the Oracle version for each of many PDBs, as each is
unplugged/plugged across the Oracle Database software version difference.
The possibility of unplug/plug, when the destination CDB is at an earlier Oracle Database
software version than the source CDB follows the exact same rules as for backing out a patch,
or downgrading, in a non-CDB. (The law says the value of the compatible parameter must be
equal to that of the earlier version. And practical reality adds the requirement that not one of
the customer-created artifacts relies, semantically, on functionality thats unique to the newer
version.) We shall use backing out a patch to the Oracle version as the collective term for both
backing out a patch and downgrading the Oracle Database software version. The account
above shows that the considerations for backing out a patch to the Oracle version are
identical to those for patching the Oracle version.
Finally, in this section, its useful to consider patching the Oracle version for an entire CDB
with its many PDBs as a single exercise. At the least aggressive end of the spectrum, all the
changes are limited to just to the root. Therefore, the time to patch the environment for n
application backends, when each is housed in its own PDB and the entire CDB is patched,
will be about the same as that to patch the environment for one application backend when this
is housed in its own non-CDB. In other words, the multitenant architecture allows patching
the Oracle version for n application backends for the cost of patching the Oracle version for
one application backend in the non-CDB architecture. We expect this approach to be
preferred in development and test environments where the users are required all to move to a
new version together, and thereafter to use only that. And we expect the unplug/plug
approach to be preferred in production environments where certification of each
consolidated application backend for the new version will follow its own schedule.
The section Remote cloning with GoldenGate replication as an alternative to unplug/plug on page 24
discusses an approach which effectively achieves hot unplug/plug.
June 2013
page 21
Oracle Multitenant
_________________________________________________________________________________________________________________
Unplug/plug for responding to SLA changes
The new unplug/plug paradigm is also very useful for responding quickly to SLA changes.
Again, the source and destination CDBs should share a filesystem so that the PDBs datafiles
can remain in place.
We expect, therefore, that customers will usually choose to have several CDBs on the same
platform, at different Oracle Database software versions, and configured differently to meet a
range of SLAs.
Cloning a PDB
An unplugged PDB is a complete, but latent, representation of everything that defines an
application backend, that typically has been in use and therefore holds quota-consuming data.
If an identical copy in other words a clone of such an application backend is needed,
while it is in use, then you could unplug the PDB, use operating system methods to copy all
the files, plug the original files back in, and plug in the cloned files, using a different name, and
possibly into a different CDB13. This thought experiment gives the clue to how the clone PDB
SQL statement works. Without unplugging the source PDB, the foreground process copies
its files and plugs these in as the clone. This is shown in Figure 8.
PDB_1
clone of
PDB_1
file copy
file copy
clone of
clone of
PDB_1
root
Figure 8 Using the foreground process to copy a PDBs datafiles to create cloned
The foreground process allocates a new globally unique identifier for the cloned PDB. The
clone records the globally unique identifier of the PDB from which it was copied, and this
lineage can, of course, be an arbitrarily long chain.
The multitenant architecture allows creating the cloned PDB in the same CDB as the source
PDB or in a different CDB, as long as there is Oracle Net connectivity between the two
CDBs. We will use the terms local cloning and remote cloning to distinguish between these choices.
13. Strictly speaking, this is unsound. The create PDB SQL statement allocates it a globally unique identifier, and
this travels with it across unplug/plug operations. Clearly two PDBs ought not to have the same globally
unique identifier. Therefore, you must not manually copy the files of an unplugged PDB. Rather, if you want
to clone, use the clone PDB SQL statement. (This also allows cloning from an unplugged PDB see Cloning
from an unplugged PDB on page 24.) And if you want an insurance copy, use RMAN backup or Data Guard.
June 2013
page 22
Oracle Multitenant
_________________________________________________________________________________________________________________
Cloning a PDB using full copy
Because Oracle Database is doing the file copy, Oracle parallel server processes can be
recruited to reduce the total time for the task. Moreover, the datafiles that are to be copied
contain Oracle data blocks, and the Oracle binaries understand what these are. Therefore, the
degree of parallelism is not limited by the number of datafiles, nor even by coarse-grained
allocation units within these understood by the operating system; rather, it is limited by the
number of Oracle data blocks within the set of datafiles. This is so large that, in practice, the
degree of parallelism is limited only by the number of Oracle parallel server processes that can
be dedicated to the clone PDB operation, given other concurrent activity on the machine.
The multitenant architecture allows the clone PDB operation to be done without quiescing the
source PDB but this is not supported in 12.1.0.1. (The attempt causes ORA-65081:
database or pluggable database is not open in read only mode.) The challenge is identical to the one
that is met by RMAN online backup: copy a set of datafiles, starting at time t, when during the
time it takes to make the copy, some of the Oracle data blocks in these files are changing. The
solution is to notice if the to-be-copied block has changed since time t and, if it has,
reconstruct it as it was at time t using undo information. Clearly the RMAN approach can be
re-purposed for the clone PDB clone operation. We shall refer to clone PDB, without quiescing
the source PDB, as hot cloning14.
Cloning a PDB using snapshot copy
For some time, filesystem vendors, such as Oracle Corporation (with Sun ZFS), or NetApp,
have exposed a method to make a copy of an arbitrarily large file in times measured in a few
seconds or less. The approach takes advantage of a generic notion, relevant for many other
kinds of structures besides files, called copy-on-write.15. Briefly, when the notion is applied to
copying a file, advantage is taken of the fact that the blocks are accessed through a separate
record that bears the files name and that lists pointers to the files blocks. Rather than copying
all the blocks, just the list of pointers is copied, and this is given the name of the new file. So
far, each block in the file is pointed to both from the source files pointer list and from the
copy files pointer list. No substantive storage has been consumed, and so the copy is near
instantaneous. Only when an attempt is made to write to a block in one of the files is a second
copy of the block made to allow the two files to differ in this block. Its this idea that gives the
approach its name.
When a large file is copied this way, and then changes are made to only small fraction of its
blocks, the net saving in time and machine resource is enormous. For this reason, the
approach is very popular when a clone is made for a development or testing purpose.
Typically, in this scenario, the file is deleted after a relatively short life when most of its blocks
remain unchanged.
Filesystem vendors prefer to use a term like snapshot copy. And the business benefit is
usually referred to as thin provisioning.
14. The discussion of hot cloning is included in this whitepaper because, were it not, the reader would point out
that the challenge of supporting hot cloning is the same as the challenge of supporting RMAN online backup!
As of the whitepapers timestamp, it is unknown what Oracle Database release might support hot cloning.
15. The generic ideas are described in this Wikepedia article http://en.wikipedia.org/wiki/Copy-on-write.
June 2013
page 23
Oracle Multitenant
_________________________________________________________________________________________________________________
Customers have used snapshot copy to make a thinly provisioned copy of the RMAN backup
set for a non-CDB, restoring the cloned non-CDB from this copy. (A new globally unique
identifier has to be created for the cloned non-CDB.) But the whole process involves various
separate steps, executed in various environments, and requiring different forms of authority.
Usually, because of a traditional division of labor between database administrators and storage
administrators, more than one person, each knowing different passwords, have to cooperate
and synchronize their efforts. This is not always easy to arrange!
In the multitenant architecture, the foreground process sends a request to the storage system
to copy the source PDBs datafiles using a dedicated secure protocol. The particular CDB
records the username/password credentials for the storage systems administrative user (for
the CDBs datafiles) in a wallet.
Snapshot PDB cloning is supported only when the new PDB is created in the same CDB as
the PDB from which it is cloned. Moreover, while there exists a thinly provisioned PDB, then
the PDB from which it was cloned cannot be dropped. A PDB created using snapshot copy
cannot be unplugged. Both source PDB and clone PDB can be opened in read-write mode.
In 12.1.0.1, these filesystems support snapshot PDB cloning: Sun ZFS, NetApp, and
Oracle ACFS. An error is reported if snapshot PDB cloning is attempted on any other
filesystem. (The error is ORA-17517: Database cloning using storage snapshot failed.)
Cloning from an unplugged PDB
An unplugged PDB can be used as a very convenient delivery vehicle for a complete
application backend, entirely replacing earlier methods that involve running various tools (for
example SQL*Plus, Data Pump, and the like). In this use case, it would not be sound simply
to plug in the unplugged PDB into many different CDBs because each PDB so created would
have the same globally unique identifier. The plug in PDB command therefore allows the new
PDB to be created as a clone of the unplugged PDB so that it is allocated its own globally
unique identifier. Code_6 shows the SQL statement.
In a variant of this usage, a set of gold master unplugged PDBs, representing useful starting
points for, for example, stress testing or debugging of application logic, might be established
at a central location at a customer site.
Remote cloning with GoldenGate replication as an alternative to unplug/plug
Should hot cloning be supported, then it would be possible to use remote cloning to establish
a new PDB in the CDB where otherwise it would have been established using unplug/plug,
without yet causing any downtime for the application whose application backend is housed in
the to-be-moved PDB. Then GoldenGate replication could be used, having noted the SCN at
which the hot cloning started, to catch up the cloned PDB and then keep it tracking. The
steady tracking state is analogous to that which characterizes the use of transient logical
standby for rolling upgrade to the Oracle Database software version. Of course, therefore,
the procedure to cutover the client-side application would be the same. In other words,
remote cloning across a difference in Oracle Database software version between source and
destination CDBs would be the natural counterpart, for a PDB, to the established transient
logical standby method for a non-CDB.
June 2013
page 24
Oracle Multitenant
_________________________________________________________________________________________________________________
The syntax for the clone PDB SQL statement
Code_3 shows the basic clone PDB SQL statement.
-- Code_3
create pluggable database PDB_2 from PDB_1
The semantics are create a clone of PDB_1 and call the resulting new PDB PDB_2.
Code_4 shows the clone PDB SQL statement for remote cloning.
-- Code_4
create pluggable database PDB_2 from PDB_1@CDB_02_link
The semantics are create a clone of PDB_1, to be found in the CDB whose root is denoted
by CDB_02_link, and call the resulting new PDB PDB_2. (Alternatively, the database link
may denote the to-be-cloned PDB.)
The database link encapsulates the specification of the location of the source CDB (it
specifies listener name, listener port, and service name, which leads to the database and its
files). It also specifies the authorization to start a session whose current container is the root of
the source CDB. Notice that, once location and authorization are established, the transport of
the files uses a suitable low-level protocol and is parallelized, using Oracle parallel server
processes as described. The files are not transported over the database link.
Code_5 shows the clone PDB SQL statement using snapshot copy.
-- Code_5
create pluggable database PDB_2 from PDB_1 snapshot copy
The semantics are create a clone of PDB_1 using underlying the filesystems
thin provisioning approach, and call the resulting new PDB PDB_2.
Code_6 shows the clone PDB SQL statement cloning from an unplugged PDB.
-- Code_6
create pluggable database PDB_2 as clone
using '/u01/app/oracle/oradata/.../pdb_1.xml'
copy
The semantics are create a clone of the unplugged PDB PDB_1, and call the resulting new
PDB PDB_2, copying the unplugged PDBs datafiles to a new set to that they may be
changed independently of the source.
The three operations create PDB, plug in PDB, and clone PDB are all variants of the
create pluggable database SQL statement. As such, each allows the path_prefix clause.
Creating a PDB
Rather than constructing the data dictionary tables that define an empty PDB from scratch,
and then populating its Obj$ and Dependency$ tables, the empty PDB is created when the CDB
is created. (Here, we use empty to mean containing no customer-created artifacts.) It is referred
to as the seed PDB and has the name PDB$Seed. Every CDB non-negotiably contains a
seed PDB; it is non-negotiably always open in read-only mode. This has no conceptual
significance; rather, it is just an optimization device. The create PDB operation is implemented
as a special case of the clone PDB operation. The size of the seed PDB is only about 1 gigabyte
June 2013
page 25
Oracle Multitenant
_________________________________________________________________________________________________________________
and it takes only a few seconds on a typical machine to copy it. The choice to use snapshot
PDB cloning is not available for create PDB.
The syntax for the create PDB SQL statement
Code_7 shows the basic create PDB SQL statement.
-- Code_7
create pluggable database PDB_1
path_prefix = '/u01/app/oracle/oradata/pdb_2_Dir'
admin user PDB_1_Admin identified by p
roles = (DBA, Sysoper)
The semantics are create a brand-new PDB called PDB_1, ensure that any directory objects
created within the PDB are constrained to the specified subtree in the filesystem that the
CDB uses, create a local user16 in the new PDB called PDB_1_Admin to be its administrator,
and grant it the given list of roles.
Dropping a PDB
A PDB that is to be dropped must be closed17.
There are two use cases for the drop PDB operation. The first is the obvious one, when the
PDB simply is not needed any more. This would be common in a non-production
environment where a PDB that represents a starting point for a specific development task, or
is under investigation, is repeatedly cloned and dropped. We refer to this as a destructive drop.
This is shown in Code_8.
The second use case is less obvious. The unplug PDB operation leaves the PDB still known in
the the roots metadata; and its datafiles are still listed in the CDBs control file. This is so that
RMAN backup can be used to record the state of just this one PDB as it was at the moment
it was unplugged. Therefore, whether or not a backup is to be made, the unplug PDB
operation must always be followed by the drop PDB operation either immediately, if no
backup is to be taken, or after the backup is completed successfully. Of course, the intention
of the plug in PDB operation implies that the datafiles must be retained. We refer to this as a
non-destructive drop. This is shown in Code_9.
The syntax for the drop PDB SQL statement
Code_8 shows the destructive drop PDB SQL statement.
-- Code_8
drop pluggable database PDB_1 including datafiles
The semantics are drop the PDB called PDB_1, and remove all of its datafiles without trace.
Obviously, this should be used with caution.
16. We shall define the term local user in The dynamic aspects of the multitenant architecture: the Oracle instance, users, and
sessions on page 31.
17. The column gv$PDBs.Open_Mode has these three allowed values: MOUNTED, READ ONLY, and READ WRITE. This is
explained in The SGA is logically virtualized on page 34.
June 2013
page 26
Oracle Multitenant
_________________________________________________________________________________________________________________
Code_9 shows the non-destructive drop PDB SQL statement.
-- Code_9
drop pluggable database PDB_1 keep datafiles
The semantics are drop the PDB called PDB_1, but leave all of its datafiles in place.
Why its important that create PDB, clone PDB, drop PDB, and unplug/plug
are SQL statements
The create PDB and drop PDB operations are functionally equivalent to using dbca to create, or
to delete, a non-CDB but dbca can be used only by logging on to the machine where the
relevant Oracle Home is installed, as the operating system user that owns the software
installation, and therefore owns the files of any other databases that have been created within
that software installation. Therefore, only very trusted people are able to do these
provisioning tasks. The clone PDB operation is functionally equivalent to using, for a
non-CDB, a rather complex sequence of steps that typically involve cloning an
RMAN backup set, and then restoring the non-CDB from the resulting set. This, too,
requires logging on as the operating system user that owns the Oracle Home. The nearest
functional equivalents, for a non-CDB, to the unplug PDB and plug in PDB operations are
Data Pumps full database export and full database import. These, too, require operating
system authorization as the Oracle Home owner to copy or move the dump files.
Recall, too, that the unplug PDB and plug in PDB operations can be used to achieve the effect
of patching the Oracle version of a PDB. This operation, too, for a non-CDB requires
operating system authorization as the Oracle Home owner.
In contrast, the SQL statements that implement create PDB, clone PDB, unplug PDB,
plug in PDB, and drop PDB can be done from a client machine and need only authorization as
suitably privileged Oracle Database users. And the statements are direct atomic expressions
of the semantic requirements of the intended operation. Moreover, except when physical full
copy, or transport, of datafiles is involved, the SQL statements can complete in times
measured in seconds and this includes the case of snapshot PDB cloning.
PL/SQL can be used simply for automation, for example to encapsulate closing a PDB,
unplug PDB, and the subsequent non-destructive drop PDB; and plug in PDB and then opening
it. Tools such as SQL Developer and Enterprise Manager18 expose the functionality of the
PDB provisioning SQL statements directly.
The net result is a very powerful new paradigm for database provisioning.
Unplug/plug and clone PDB for CDBs protected by Data Guard
The standby database will respond automatically to the create PDB and clone PDB operations in
the primary database. But for the plug in PDB operation in the primary database, its datafiles
will need to be made available at the standby database in just the same way that the datafiles
for transportable tablespaces need to be handled. Similarly, after the drop PDB operation with
18. Enterprise Manager exposes provisioning functionality for non-CDBs for pre-12.1 non-CDBs; but this relies
on installing and using server-side agents and a scheme for operating system authorization. The
implementation of the corresponding functionality for PDBs is much more straightforward and, as has been
explained, the operations execute much faster on PDBs than on non-CDBs.
June 2013
page 27
Oracle Multitenant
_________________________________________________________________________________________________________________
the keep datafiles choice, which follows the unplug PDB operation, the datafiles of the
unplugged PDB, must be removed manually from the standby environment.
--------------------------------------------------------------
6 Как воспринимать (внедрять) не CDB как PDB
-- Прямое внедрение 12.1 non-CDB как PDB
-- Внедрение (принятия понимание) контента non-CDB
How to adopt a non-CDB as a PDB
There are two approaches: direct adoption of a 12.1 non-CDB as a PDB; and adoption of the
content of a non-CDB, using for example Data Pump, into an empty PDB.
Direct adoption of a 12.1 non-CDB as a PDB
Oracle Database 12c supports both the new multitenant architecture and the old
non-CDB architecture. A pre-12.1 non-CDB cannot be directly adopted as a PDB, and so an
it must be upgraded in place, using the usual approach. The actual direct adoption is very
simple both conceptually and practically. The non-CDB is simply shut down and then
treated as if it were an unplugged PDB. Recall that an unplugged PDB has an external
manifest that is generated by the unplug PDB operation. Therefore, before shutting down the
to-be-adopted non-CDB, it must be put into READ ONLY mode and then the procedure
DBMS_PDB.Describe() must be executed, nominating the path for the manifest as its only
argument just as a path must be nominated when using the unplug PDB operation.
After shutting down the to-be-adopted non-CDB, it would be natural to do an ad hoc
RMAN backup.
The non-CDBs datafiles, together with the manually created manifest, can now be treated as
if they were an ordinarily unplugged PDB and simply plugged in to the target CDB and
opened as a PDB. However, as will be explained immediately, it must be opened with the
Restricted status set to YES. The tablespaces holding quota-consuming data are immediately
viable, just as if this had been a Data Pump import using transportable tablespaces. However,
the former non-CDBs data dictionary so far has a full description of the Oracle system. This
is now superfluous, and so it must simply be removed. While still with the Restricted status set
to YES, the noncdb_to_pdb.sql script (found on the admin_directory under Oracle Home) must be
run. Now the PDB may be closed and then opened ordinarily.
We shall refer to this adoption method as the upgrade-and-plug-in adoption approach.
Adoption of the content of a non-CDB
The approaches described in this section are inevitably possible by virtue of the
PDB/non-CDB compatibility guarantee. Data Pumps full database export and import can be
used to migrate most of the customer-created artifacts from the non-CDB to the new PDB.
New in 12.1, Data Pump supports full database export, and full database import, making
maximum possible use of transportable tablespaces, using single commands. The capability is
called Full Transportable Export/Import. This enhancement has been backported to 11.2.0.3. We
shall refer to this adoption method as the Data Pump adoption approach. However, database
artifacts of some kinds, for example XML schemas, directories and grants made to public,
cannot be moved using Data Pump. These will need to be migrated using ad hoc methods.
Notice that when the size of the to-be-adopted non-CDB is relatively small, and when
Data Pump is able to handle all the content, it might be quicker to use the Data Pump
adoption approach than to use the upgrade-and-plug-in adoption approach. Moreover, a
consolidation exercise often involves moving application backends from old equipment to
modern equipment and this might mean cross-endianness migration. As explained in
Unplug/plug across different operating systems, chipsets, or endiannesses on page 18, the Data Pump
adoption approach is the only option in this scenario.
Alternatively, GoldenGate replication can be used to populate to new PDB and then to keep
it tracking ongoing changes in the source non-CDB. Then the client-side application code can
be moved from the old non-CDB to the new PDB in a brief brownout using the same
cutover approach as is used in connection with the transient logical standby method for
patching the Oracle version for a non-CDB.
--------------------------------------------------------------
7 Динамические аспекты мультиарендной архитектуры экземпляр, пользователи и сессии:
-- Обшее про пользователей, роли и разрешения
--- Локальные пользователи и локальные роли
--- Общие пользователи и общие роли
--- Общая выдача привелегий и общие роли
--- Пользовательские общие пользователи и общие роли
-- Сервисы и сессии
-- Смена контейнера текущей сессии для установленных сессий
-- SGA логически виртуализирован
-- Представления словаря данных и производительности
The dynamic aspects of the multitenant architecture:
the Oracle instance, users, and sessions
This section explores the consequences of the fact that it is the entire CDB that is opened by
the RAC instance.
Commonality of users, roles, and granting
In a CDB, we distinguish between local users and a common users. The fact that there are two
kinds flows inevitably from the PDB/non-CDB compatibility guarantee. This requires two
things:
that each PDB in the same CDB can have a customer-created user called, say, Scott
where these are independent and just happen, coincidentally, to have the same name
that Oracle-supplied users like Sys and System must be present in every container with a
uniquely defined, documented purpose and characterization.
Локальные пользователи и локальные роли
Как показано в разделе "... горизонтально партицированный словарь ..." каждая PBD внутри конкретной CDB может иметь пользователя Scott.
Этот пользователь локален, объявлен точно и только в PDBs представлении User$, и доступен тлько внутри PDB. Пользователь Scott для каждой PDB
может иметь уникальный пароль. То же касается и локальных ролей, доступных только внутри конкретной PDB. Ни локальный пользователь, ни локальная
роль не могут быть созданы в корне
Общие пользователи и общие роли
С другой стороны сессии, использующие PDB внутри конкретной CDB должны видеть идентичный набор предоставляемых вендором объестов, как и сессии,
использующие другие PDB в этой CDB. Эти объекты, конечно, включают пользователей навроде Sys and System и роли навроде DBA и Select_Catalog_Role.
Sys и System - это общие пользователи, а DBA и Select_Catalog_Role - общие роли. Имя и пароль общих пользователей определяются в корне, и видны
во всех PDB текущей CDB (настоящих и будущих) с этими именами и паролями
Соответственно, общие роли также определяются в корне и видны всюду. Объекты навроде Sys.DBMS_Output и System.Sqlplus_Product_Profile в силу некоторых
причин также должны присутствовать в каждом контейнере в виде уникального определения, они называются общими объектами и создаются в корне.
Пользователь не может создавать общие объекты. Такие объекты представлены в словаре PDB отдельной строкой в Obj$, соответствующей строек в корневом
CDB$Roots Obj$ по имени (соответствуют также Owner, Object_Name, Namespace). Этот механизм позволяет обеспечивает для PDB мгновенную жизнеспособность
после отключения/подключения между CDBs с учётом зависимостей в Dependency$, сливая вместе общие и локальные объекты, фактически заполняя Dependency$
значениями Object_ID
Выданные общие привелегии и общие роли
Эффект от выданных привелегий или ролей текущего контейнера представлен в SysAuth$ и ObjAuth$ внутри PDB. В результате грантованное видно PDB, что
верно даже если презентуются общему пользователю и роли. Поэтому конкретный общий пользователь или общая роль могут иметь различные наборы прав в
каждой PDB. Однако совместимость требует, чтобы предопределённые общие пользователи навроде Sys и System, предопределённые общие роди навроде DBA
и Select_Catalog_Role, имели общий набор прав в каждой - текущей и будущей - PDB внутри CDB. (При условии следования пользователя рекомендациям
вендора, когда не удаляются права предустановленным вендором пользователям). Это поддерживается специальными вставками и SQL запрос grant, например:
grant Create Session to A_Common_User container = all
Создаваемые пользователем общие пользователи и общие роли
Используется в случае создания для общего пользователя авторизационного механизма для решения административных задач для всей CDB или нескольких PDB
с общим именем, паролем и аудитом, что следует сложившейся ранее best-practice по блокированию предопределённых вендором пользователей и созданию
покупателем своих пользователей для административных задач. В CDB это решается общими пользователями, которые обычно не имеют своих объектов. Однако
объекты могут понадобиться - например процедуры для администрирования, не являющиеся частью прикладных решений. В CDB общий пользовтаель может иметь
локальные объекты в корне, не препятствуется иметь и объекты в PDB. Но рекомендуется для локальных объектов иметь локального пользователя. Эти
соображения определяют вариант с общим пользователем потребителя. Именка таких общих пользователей должны начинаться с C## или c##, например:
create user c##u1 container = all identified by p
Терма (кляуза, подстрока, класс) container = all используется также для создания общих ролей. Помните, что локальный пользователь не может получить
Сервисы и сессии
Для создания сессии на фоне non-CDB используя Oracle Net, нужно обеспечить следующие пять факторов: listener location, listener port, service name,
username, and password. Первые два определяют листенер, остальные сервис, запускающий foreground процесс, запускаемый экземпляром (в т.ч. RAC),
обслуживающим базу, под пользователем Sys. Затем запрашивается таблица User$ на наличие корректных имени и пароля, и определяется наличие привелегии
Create Session privilege. Если проверки удачны, пользователь обслуживается, иначе процесс удаляется и пользователь отключается. Для варианта с PDB
всё также, но есть дополнение. Ключевые моменты присутствуют. Когда запускается процесс от Sys, контейнером является корень, Он смотри значение
свойств запрошенного сервиса (в 12.1 появляется возможность указать PDB, если не указывать - подразумевается корень). Сессия переключается на
указанный контейнер, и только потом идёт опрос таблицы User$. В остальном всё также
Изменение текущего контейнера для установленной сессии: alter session set container = PDB_2. Пользователь должен быть известен в новом контейнере и
должен иметь системну привелегию Set Container. Конечно он должен быть известен и в старом контейнере - это значит только общий пользователь не
получит ошибки. Также необходимо финализировать все транзакции в старом контейнере для переключения в новый
Запуск alter session set container допустим как высокоуровневый запрос. Запуск новой для 12.1 DBMS_Sql.Parse() создаёт эффект смены контейнера внутри
PL/SQL. По этим резонам мы описываем подход использующий это как DBMS_Sql.Parse трамплин. Формальный параметр Container определяет положение
отдельного запроса при разборе. Когда предложение завершается, текущий контейнер автоматически без договорённостей сбрасывается к состоянию вызова
DBMS_Sql.Execute(). Это верно также если удалённо выполненный запрос привёл к ошибке. Code_13 shows an example.
begin
...surrounding PL/SQL context...
-- For example
Stmt := 'create table t(PK...)';
declare
Cur integer := DBMS_Sql.Open_Cursor(Security_Level=>2);
Dummy integer;
begin
Dbms_Sql.Parse(c=>Cur,Statement=>Stmt,Container=>Con_Name,Language_Flag=>DBMS_Sql.Native);
Dummy := DBMS_Sql.Execute(Cur);
DBMS_Sql.Close_Cursor(Cur);
end;
...surrounding PL/SQL context...
end;
Использование DBMS_Sql.Parse() корректно только для запуска из CDB$Root. Эти правила гарантируют, что сессия, созданная локальным пользователем, не
сможет сбросить PDB, определённую через service name при подключении. Это подразумевает что для локальных пользователей модель изоляции меджу PDB
внутри CDB такая же, как для не CDB конфигураций под одним пользователем ОС. Это пригодно для использования alter session set container в
административных скриптах для CDB, и позволяет избежать повторений СONNECT и засвечивания паролей. Метод DBMS_Sql.Parse() применим для
администрирования CDB через PL/SQL.
Логическая виртуализация SGA
Within-database consolidation delivers its consolidation density benefit because all the
application backends share, per RAC instance, the same SGA. Using schema-based
consolidation, the SGA simply ends up with a population whose items, though they reflect all
of the application backends, and the Oracle system, are not attributed as such. Only the
human, who thinks about it, realizes that this is the case. Using PDB-based consolidation,
each of the items (most notably data blocks and library cache structures like child cursors) is
annotated with its provenance. In other words, the SGA is logically virtualized. This is
significant. The data dictionary is physically virtualized, to bring pluggability; and the SGA is
logically virtualized to retain the physics of within-database consolidation. This is shown in
Figure 9 on page 35.
20. Otherwise, the normal PL/SQL rules apply: the code may be any of the three kinds (anonymous block,
invokers rights unit, or definers rights unit) and the privilege test is based on the current user, and only that.
21. To reinforce this principle, there is no direct way to reference an object in one PDB from a SQL statement
issued, or part of the code that defines an object, in another PDB. We deliberately decided not to invent an
three-part naming scheme (PDB-name, schema-name, object-name) that would allow cross-PDB name
resolution. if you want, from one PDB, to reference an object in another PDB, the you must use a database
link.
Instance_4
Instance_3
Instance_2
Instance_1
PDB_1
PDB_2
PDB_3
root
Figure 9 PDB-to-RAC-instance affinitization. The arrows on the right are color-coded to show the
affinitization between each PDB and each of the RAC instances.
Some customers have followed the practice, using schema-based consolidation, of affinitizing
the sessions that support users working with a particular application backend to a particular
set of RAC instances. They have done this by following a self-imposed discipline of using
specific service(s) to start sessions dedicated to a particular application backend.
The convention has formal support in the multitenant architecture. A PDB can be in READ
WRITE mode, in READ ONLY mode, or in MOUNTED mode. The mode is shown in the
performance view column gv$PDBs.Open_Mode and it can be set explicitly, and differently,
for each PDB in each RAC instance. Notice that the MOUNTED mode is the closest a PDB can
get to idle. This is precisely because the RAC instance deals with the CDB as a whole, so it is
meaningless to want to shut it down for just a specific PDB. The Open_Mode can be set, using
the alter pluggable database SQL statement, for any PDB when the current container is the root;
and can be set for a particular PDB when the current container is that PDB. For
compatibility, the SQL*Plus commands STARTUP and SHUTDOWN can be issued when the
current container is a PDB. They are translated into the corresponding alter pluggable database
SQL statements.
Orthogonally to the Open_Mode, the Restricted status can also be set to NO or to YES. There are
five distinct combinations of Open_Mode and the Restricted status for a PDB. (When the
Open_Mode is MOUNTED, then the Restricted status can be only null.) The alter pluggable database
SQL statement can be used to go directly from any such combination to any other one by
using the keyword force, as illustrated in Code_14.
-- Code_14
-- PDB_1 starts in READ WRITE mode
alter pluggable database PDB_1 open read only force
In this example, all sessions connected to PDB_1 and involved in non-read-only transactions
will be terminated, and their transactions will be rolled back. This is a nice improvement in
usability compared to the rules for the corresponding mode changes for a non-CDB.
The notifications that are sent from a RAC instance where an SGA change takes place to the
other RAC instances, to avoid disagreement on information that is cached in several SGAs,
are pruned at a coarse level in the multitenant architecture. There is no point in informing
RAC instances where a particular PDB is not open of changes that have occurred to its items
cached in the RAC instances where it is open.
The multitenant architecture provides, therefore, a simple declarative model for
application-backend-to-RAC-instance affinitization that more reliably implements the
intention, and provides better performance, than the hand orchestrated scheme to meet this
goal using schema-based consolidation. This idea is discussed more in PDB-to-RAC-instance
affinitization on page 45.
Data dictionary views and performance views
The PDB/non-CDB compatibility guarantee implies that the data dictionary views and
performance views, queried when the current container is a PDB, must show only
information about artifacts defined within that PDB together with those defined within
the root. For example, when the Sample Schemas are installed in PDB_1, and when PDB_1 is
the current container, then the query shown in Code_15
-- Code_15
select Owner, Object_Name
from DBA_Objects
where Owner = 'SYS'
and Object_Type like 'VIEW'
and Object_Name like 'ALL%'
union
select Owner, Object_Name
from DBA_Objects
where Object_Type like 'VIEW'
and Owner in (select Username from DBA_Users where Common = 'NO')
will include these results:
SYS
SYS
SYS
SYS
SYS
SYS
SYS
HR
OE
SH
ALL_ARGUMENTS
ALL_DIRECTORIES
ALL_ERRORS
ALL_INDEXES
ALL_OBJECTS
ALL_TABLES
ALL_VIEWS
EMP_DETAILS_VIEW
PRODUCTS
PROFITS
However, it will not include any objects defined within PDB_2 or any other PDB in the CDB.
In the same way, when PDB_1 is the current container and when v$Sql is queried, information
will be seen only about SQL statements issued when PDB_1 is the current container.
The multitenant architecture brings new rules for the results when data dictionary views and
performance views are queried when the current container is the root. Potentially, the results
will be the union over the occurrences of the view in question across all presently open
containers. The rows are distinguished because the views have a new Con_ID column in 12.1.
This meets the business goal of supporting a single system image across the whole CDB. For
example, violations in customer-defined practices for naming conventions can easily be
policed. (Some customers insist that names never include special characters like single-quote,
double-quote, semicolon, or question-mark.) Another use might focus on finding the
longest-running SQL statements, CDB-wide.
The performance views simply acquire the Con_ID column. But, for the data dictionary
views, the Con_ID column is exposed only in a new family whose names start with CDB_.
These extend the concept of the DBA_ data dictionary views; the All_ and User_ flavors are
not extended this way.
The views can return rows for more than one container (that is, those acquired the new
Con_ID column) are collectively called container_data views. When the current container is a
PDB, then every container_data view shows only rows whose Con_ID value denotes this PDB,
or denotes the CDB as a whole. But when the current container is the root, then the
container_data views might show rows from many containers. Recall that a local user cannot be
created in the root, and so only a common user might see results from a container_data view with
more than one distinct value of Con_ID. The set of containers for which a particular
common user might see results in a container_data view is determined by an attribute of the user
(set using the Alter User SQL statement).
This attribute can specify, at one end of the spectrum, illustrated in Code_16, just one
particular container_data view for, say, just two named PDBs.
-- Code_16
-- Allow c##u1 to see data for just CDB_Objects
-- in CDB$Root, PDB_1 and PDB_2
alter user c##u2
set container_data = (cdb$root, pdb_001, pdb_002)
for Sys.CDB_Objects
container = current
Notice that this SQL statement is allowed only when the current container is the root, and that
the attribute can be set only locally in the root. Notice, too, that CDB$Root must always be
included in the list.
At the other end of the spectrum, illustrated in Code_17, it can specify all container_data views,
present and future (across an Oracle Database release boundary) for all containers, present
and future. The Oracle-supplied users like Sys and System are configured this way.
-- Code_17
-- Allow c##u2 to see data for every container, present and future
-- in every container_data view
alter user c##u2
set container_data = all
container = current
--------------------------------------------------------------
8 Сравнение выбора CDB и выбора PDB
-- Выбор - использовать вообще только CDB
--- Сессии СУБД Oracle и особенности платформ
--- The spfile, control files, and password file
--- Data Guard, RMAN backup, redo, and undo
--- Character set
--- CDB-wide initialization parameters and database properties
--- Отчёты AWR
-- Вариант, когда возможна кастомизация для каждой PDB
--- Восстановление на заданную точку времени отдельной PDB
--- Оперативный бэкап RMAN для PDB
--- alter system flush Shared_Pool
--- Инициализационные параметры и свойства базы данных, устанавливаемые в PDB
--- Ошибка ORA-65040
Per CDB choices versus per PDB choices
Consolidation inevitably implies trading out some of the autonomy that was enjoyed by the
previously independently managed application backends in order to win the sought-after
reduction in capital expense and operating expense. This section sets out the choices that can
be made only for the CDB as a whole, and gives some examples of the remaining choices
those that can be made differently for each PDB.
Choices that can be made only for the CDB as a whole
Oracle Database software version, and platform specifics
Just as with schema-based consolidation, the central consolidation notion is to house many
distinct application backends within the same database, sharing (per RAC instance) the same
SGA and the same set of backround processes. This means, of course that every PDB within
the same CDB must be at the same Oracle Database software version. It is no more
meaningful to ask if different PDBs in the same CDB can be at different Oracle Database
software versions than it is to ask if different schemas in the same non-CDB can be at different
Oracle Database software versions. Both within-database consolidation models imply, of
course, a single choice of platform type and operating system type and version for all the
consolidated application backends.
The unplug/plug paradigm for patching the Oracle version removes the discomfort that
otherwise would be caused by the fact that CDB as a whole is at a particular Oracle Database
software version. Further, the mobility that this brings loosens the tie that schema-based
consolidation establishes between an application backend and the platform, and operating
system type and version, on which the non-CDB that houses it runs.
The spfile, control files, and password file
These files are common for the CDB as a whole. This implies that a PDB cannot literally have
its own spfile. We shall see in PDB-settable initialization parameters and database properties on
page 42 that some parameter values can be set persistently with alter system within the scope of
a PDB. These are persisted appropriately but not actually in the spfile. By extension of this
you cannot name a pfile when you open a PDB. Therefore, if you want to dump the values of
parameters that have been set specifically with alter system within the scope of a PDB, then you
must write a SQL query to do this. Correspondingly, to impose these values, you must
program a sequence of alter system SQL statements.
Data Guard, RMAN backup, redo, and undo
Customers who have used schema-based consolidation have shown significant reduction in
operating expense because they can set up, and operate, Data Guard for a single non-CDB
that houses many different application backends rather than, as they used to before
consolidation, managing Data Guard for each individual application backend as a separate
task. This is the canonical example of the manage-as-one principle. In the same way, they have
derived operating expense savings by operating a single scheduled RMAN backup regime to
benefit many different application backends. However, as mentioned in Striving to achieve
maximum consolidation density on page 5, this doesnt give a generally workable solution for
application backend point-in-time-recovery. We shall return to this point in Ad hoc
RMAN backup for a PDB on page 42.
Both Data Guard and RMAN backup rely on the redo logs: Data Guard applies redo
continuously at the standby site; and RMAN backup uses redo when restoring to roll forward
from the time of the backup to the required restore time. Therefore, to deliver the same
manage-as-one savings for PDB-based consolidation as schema-based consolidation delivers,
the CDB as a whole has a single redo stream. This implies that, just as is the case with the
SGA, the redo log is logically virtualized: each redo log entry is annotated with the
container identifier for where the change that it records occurred. Redo and undo go hand in
hand, and so the CDB as a whole has a single undo tablespace per RAC instance. The undo,
then, is also logically virtualized: here too, each undo record is annotated with origin
container identifier. These two points inform the discussion about the performance
implications:
Firstly, the situation in this regard, when using PDB-based consolidation is the same as
when using schema-based consolidation. And customers have demonstrated that
schema-based consolidation doesnt harm performance. In the bigger picture, other factors
are at work most notably that the set of application backends is served by far fewer
backround processes in total, when either of the two within-database consolidation models
is used, and that the application backends jointly make much more effective use of memory
when a single SGA is shared between them all than when each has its own individually
sized, and individually constraining, SGA.
Secondly, new within-redo and within-undo indexing schemes can speed up access to the
records for the relevant PDB. Moreover, because of the functional independence of the
individual logically virtualized partitions with the redo and undo, it is practical for
concurrent processes to access these without waiting for each other.
Customers who aim to increase return on investment by consolidation usually do their own
empirical investigations using representative models of their own consolidation candidates.
Character set
The multitenant architecture does allow the possibility the each PDB might have its own
character set. However, allowing this would detract from the manage-as-one benefit.
Further, a trend has emerged over recent years where a huge number of applications have an
international, and multilingual, user base. And this is reflected by the fact that an
ever-increasing proportion of client-side processing is done using Unicode. This implies
inefficiencies as data is converted backwards and forwards between client and database if the
data isnt store in Unicode in the database.
It was therefore decided to allow the character set to be determined only for the CDB as a
whole. We recommend, therefore, that Unicode (AL32UTF8) be used as the CDBs character
set.
A consideration remains, of course, for legacy applications where the application backend
uses a specific character set and cannot economically be re-engineered. This is where
advantage would be taken of the fact that you can have several CDBs on the same platform,
each created with its own character set. (This is just one example of a more general principle.
The most obvious reason to have more than one CDB on the same platform is to allow each
to have a different Oracle Database software version.)
CDB-wide initialization parameters and database properties
The v$System_Parameter view family has a new column in 12.1, IsPDB_Modifiable, with allowed
values FALSE and TRUE. (We shall consider those with IsPDB_Modifiable TRUE in PDB-settable
initialization parameters and database properties on page 42). About 200 have IsPDB_Modifiable
FALSE. These are some illustrative examples:
audit_file_dest
audit_trail
background_core_dump
background_dump_dest
core_dump_dest
cpu_count
db_block_size
db_name
db_recovery_file_dest
db_recovery_file_dest_size
db_unique_name
instance_name
local_listener
log_archive_dest
log_archive_duplex_dest
memory_max_target
memory_target
parallel_degree_policy
pga_aggregate_limit
pga_aggregate_target
processes
result_cache_max_size
sga_max_size
sga_target
shared_pool_reserved_size
shared_pool_size
undo_management
undo_retention
undo_tablespace
user_dump_dest
The list speaks to the manage-as-one theme.
Apart from the already discussed NLS_CHARACTERSET, all the other properties listed in the
Database_Properties view can be set using the alter database SQL statement when the
current container is a PDB.
AWR Reports
You can create AWR Reports for the CDB as a whole, and we expect this to be the level at
which scheduled reports will be run. To support ad hoc performance investigations within the
scope of a single application backend, you can also create AWR Reports for a particular PDB.
Choices that can be made differently for each PDB
PDB point-in-time-recovery
The most notable per PDB freedom is the ability to perform PDB point-in-time-recovery
without interfering with the availability of peer PDBs in the same CDB. And this ability is one
of the most significant differentiators between schema-based consolidation and PDB-based
consolidation. The former simply has no comfortable method to meet the business goal of
per application backend point-in-time-recovery. The flashback pluggable database command is
not supported in 12.1.
Ad hoc RMAN backup for a PDB
The manage-as-one principle is generally best served by performing scheduled
RMAN backup at the CDB level, as has been explained. However, occasions arise when it is
useful to take an ad hoc backup for a particular PDB. This was discussed in Dropping a PDB
on page 26 in connection with the joint use of the unplug PDB command and then the
drop PDB command (keeping the datafiles).
alter system flush Shared_Pool
As was explained in The dynamic aspects of the multitenant architecture: the Oracle instance, users, and
sessions on page 31, the data blocks in the block buffer and the library cache structures are
annotated with the container identifier. This gives immediate meaning to the effect of
alter system flush Shared_Pool when the current container is a PDB.
PDB-settable initialization parameters and database properties
Every initialization parameter that, in the v$System_Parameter view has both IsSes_Modifiable
and IsSys_Modifiable not equal to FALSE, can be set using alter system when the
current container is a PDB. In other words, all such parameters have IsPDB_Modifiable equal
to TRUE. Further, some other parameters with IsSys_Modifiable not equal to FALSE, and with
IsSes_Modifiable equal to FALSE, can also can be set using alter system with PDB scope. This is
the relatively small list in 12.1:
cell_offload_decryption
fixed_date
listener_networks
max_string_size
open_cursors
optimizer_secure_view_merging
resource_limit
resource_manager_plan
sessions
Reflecting the other allowed values, IMMEDIATE and DEFERRED, for IsSys_Modifiable, the
scope clause (scope=memory, scope=spfile, or scope=both) has the expected effect: that the value will
be persisted if requested. To honor the PDB/non-CDB compatibility guarantee, the
established alter system syntax was retained but the persistence mechanism is not, in fact,
the spfile. Rather, it is held in appropriate data dictionary tables so that both such PDB-specific
values can take effect when it is opened and the values will travel with the PDB on
unplug/plug.
The ORA-65040 error
Oracle Database supports a very wide range of SQL statements. Some of these would be
used only by the administrator who controls the overall database, under special circumstances.
In a CDB, a small subset of these administrator-only SQL statements cannot be issued in a
PDB. The attempt causes ORA-65040 operation not allowed from within a pluggable database. This is
very much by design. The PDB/non-CDB compatibility guarantee should be read in this
light. Notice that all SQL statements can be automatically issued from client-side code. But
client code thats worthy of the name application rather than, for example, something like
administration tool, like Enterprise Manager doesnt issue the statements that cause
ORA-65040. Even client code that would be called installation automation should not, if it
follows best practice, issue such statements.
--------------------------------------------------------------
9 Управление ресурсами внутри CDB и между PDB
-- вычисление ресурсов для уровня CDB в версии 12.1
-- Разделяемая и ограничивающая модели
-- Как план уровня CDB управляет сессиями, CPU, процессами Oracle parallel server и файловым вводом/выводом
-- особенности PDB-to-RAC-instance
Within-CDB, between-PDBs, resource management
The sessions using different application backends that are hosted on the same platform
compete for these computing resources:
the number of concurrent sessions
CPU
ability to use Oracle parallel server processes
file i/o
use of SGA memory and ability to allocate PGA
network i/o
Some customers decide that they want full control over the competition for every one of
these resources and therefore host each application backend in its own non-CDB in its own
virtual machine, taking advantage of operating system virtualization. However, this scheme
utterly defeats manage-as-one operating expense savings. Many customers have found that
return on investment is maximized by prioritizing the manage-as-one savings, and have
therefore used schema-based consolidation.
It is possible to use Resource Manager within the context of schema-based consolidation. But
this requires a carefully planned, and humanly policed, discipline where each application
backend is accessed only using services created for that purpose. The problem, of course, is
that with schema-based consolidation, only the human being knows how to draw the
boundaries around each distinct application backend; Oracle Database has no understanding
of this. With PDB-based consolidation, the PDB provides a powerful, declarative mechanism
that enables the human to tell Oracle Database where the boundaries are: each application
backend is installed in its own PDB, and no PDB houses more than one application backend.
Resource Manager is enhanced, in the multitenant architecture, by the ability to create a
CDB-level plan to govern the resource competition between the PDBs contained in the
CDB.
The computing resources controlled by the CDB-level plan in 12.1
The Resource Manager CDB-level plan, in 12.1, controls these:
the number of concurrent sessions
CPU
ability to use Oracle parallel server processes
file i/o but only on Exadata
But it does not control these:
use of SGA memory and ability to allocate PGA
network i/o
PDB-to-RAC-instance affinitization22 can be used as a coarse-grained approach controlling
the competition for SGA and PGA memory.
The shares and caps model
Resource Manager has implemented an industry-standard model based on two notions: the
share, and the cap23. In this scheme, each competitor is allocated a number of shares, from one
to any positive integer (but anything more than about ten might turn out to be unhelpful). At
a moment, typically only some of the competitors are active. Each of the active competitors
gets a fraction n/t of the managed resource, where n is the number of shares allocated to a
particular competitor and t is the total of the allocated shares over all the currently active
competitors. Optionally, any competitor can be given a cap; this is a fraction in the range zero
through one (often expressed as a percentage). A competitor with a cap of c never gets more
than that fraction of the managed resource, no matter what the share calculation might
indicate. Of course, such a capped competitor might get less, depending on the instantaneous
result of the share calculation.
The value of the share notion is obvious; it is the sine qua non of resource management. The
value of the cap notion is realized when the number of competitors gradually increases up to
some planned number. It ensures headroom remains for the ultimate plan, without setting
false expectations along the way. (Users are pleased by a performance improvement as
would be seen when an application is moved from one machine to a more powerful one,
uncapped, as the only application it initially hosts. But they have a notoriously short memory.
So as more and more applications are moved onto the consolidation machine, they notice,
and remember, only performance getting steadily worse. It is better, therefore, to cap the
performance for an application, that is among the first to be moved to the consolidation
machine, to the level that is expected when the consolidation exercise is complete.)
For between-PDBs resource management, when a PDB is created, it is allocated one share by
default and is not capped.
How the CDB-level plan in 12.1 manages sessions, CPU, Oracle parallel
server processes, and file i/o
When a plan is set, or modified, the effect is felt immediately by all current sessions24.
22. This is described in PDB-to-RAC-instance affinitization on page 45.
23. Here is an academic paper on the topic, published in 1995:
http://people.cs.umass.edu/~mcorner/courses/691J/papers/PS/waldspurger_stride/waldspurger95stride.pdf
And here is a developer forum posting from a vendor of operating system virtualization software:
http://communities.vmware.com/docs/DOC-7272
The notion cap is sometimes called a resource utilization limit.
24. The plan is set using alter system set resource_manager_plan = My_Plan. As noted in PDB-settable initialization
parameters and database properties on page 42, the resource_manager_plan initialization parameter can be set with
container scope. So to set the CDB-level plan, alter system will be issued when the current container is the root.
The number of concurrent sessions is subject only to capping; the shares notion is
meaningless here. In fact, the sessions cap is set using the sessions initialization parameter25.
CPU and file i/o are managed using the shares and caps mechanisms described above.
Fine-grained scheduling of sessions is performed every 100 ms.
Code_18 shows how a CDB-level plan is configured to allocate one share to PDB_1 and. three
shares to PDB_2.
-- Code_18
DBMS_Resource_Manager.Create_CDB_Plan(
'My_Plan', 'some comment');
DBMS_Resource_Manager.Create_CDB_Plan_Directive(
'My_Plan', 'PDB_1', Shares => 1);
DBMS_Resource_Manager.Create_CDB_Plan_Directive(
'My_Plan', 'PDB_2', Shares => 3);
And Code_19 shows how a CDB-level plan is modified to allocate two shares to PDB_1 and.
five shares to PDB_2, and to set caps for these at 20% and 50% respectively.
-- Code_19
DBMS_Resource_Manager.Update_CDB_Plan_Directive(
'My_Plan', 'PDB_1', New_Shares => 2);
DBMS_Resource_Manager.Update_CDB_Plan_Directive(
'My_Plan', 'PDB_1', New_Utilization_Limit => 20);
DBMS_Resource_Manager.Update_CDB_Plan_Directive(
'My_Plan', 'PDB_2', New_Shares => 5);
DBMS_Resource_Manager.Update_CDB_Plan_Directive(
'My_Plan', 'PDB_2', New_Utilization_Limit => 50);
The ability to use Oracle parallel server processes is governed by the same shares model. The
parallel_degree_policy initialization paramter must be set to AUTO. Then enough SQL statements
are run in parallel to keep the machine busy, but the queuing of SQL statements avoids
downgrade of the degree-of-parallelism. Here, the cap notion has its own separate
parameterization using the parallel_server_limit parameter in DBMS_Resource_Managers
Create_CDB_Plan_Directive subprogram and the new_parallel_server_limit parameter in its
Update_CDB_Plan_Directive subprogram.
PDB-to-RAC-instance affinitization
As explained in The dynamic aspects of the multitenant architecture: the Oracle instance, users, and
sessions on page 31, the Open_Mode of each PDB can be set to MOUNTED, READ ONLY, or READ
WRITE specifically, and therefore differently, in each RAC instance. For example, when a CDB
with eight PDBs is configured as a RAC database with eight Oracle instances, then each PDB
can be opened in exactly one RAC instance, so that each RAC instance opens exactly one
PDB. This scheme delivers the maximum possible resource isolation. But it also
compromises the sharing of SGA and backround processes that brings the high consolidation
density that is the hallmark of PDB-based consolidation (and of schema-based consolidation).
25. As mentioned in PDB-settable initialization parameters and database properties on page 42, the sessions initialization
parameter can be set using the alter system SQL statement when the current container is a PDB.
Perhaps a more sensible use of PDB-to-RAC-instance affinitization would be, with a CDB
with a couple of hundred PDBs or more, to affinitize, say, the top quarter (with respect to
requirement for processing power) to 75% of the RAC instances, and the remaining three
quarters of the PDBs to the remaining 25% of the RAC instances.
--------------------------------------------------------------
10 Отдельная PDB в CDB или не CDB
Lone-PDB in CDB versus non-CDB
Suppose that an application backend has such a high throughput requirement that a particular
platform must be dedicated exclusively to it. It could be installed either in a non-CDB or in a
PDB that (apart from the seed PDB) is the only PDB in its CDB. We shall refer to the latter
configuration as a lone-PDB. It is also referred to as the single-tenant configuration.
Is the non-CDB choice in any way better than the single-tenant configuration?
We promise that the answer is a resounding no. The PDB/non-CDB compatibility guarantee
shows that there is no functional difference. Careful testing by Oracle Corporation engineers
has proved this claim and has shown, further, that there is no performance difference.
The more interesting question is the other way round: is the single-tenant configuration better
than the non-CDB choice?
Here, the answer is yes. Even when you never exceed one PDB, the new
multitenant architecture brings significant benefits:
Unplug/plug brings you, in terms of functionality, Data Pump Generation Three.
Unplug/plug, into an empty, newly created CDB, brings you a new paradigm for patching
the Oracle version26.
This realization lead to the decision to specify the Oracle Multitenant option as allowing
between two and 252 PDBs in a particular CDB. (The seed PDB is not counted among the 252
allowed PDBs.)
The single-tenant configuration, and therefore the choice to use the multitenant architecture,
is available, for no extra cost, in each of Standard Edition, Standard Edition One, and
Enterprise Edition27.
26. Hot cloning (should a future release bring support for this) suggests this following approach: hot cloning into
a staging CDB, at the same Oracle Database software version, noting the SCN at which it was created;
followed by unplug/plug into the newer version CDB, with, then, catch-up to the source PDB, and tracking,
using GoldenGate replication. This would bring the functional equivalent of the use of transient logical
standby with greatly improved usability.
27. The Oracle Database 12c Licensing Guide sets out these terms formally.
--------------------------------------------------------------
11 Итог
Summary
We have seen that the essential difference between the old non-CDB architecture and the new
multitenant architecture is that the latter brings true within-database virtualization. This is
implemented physically in the data dictionary by virtue of the horizontal partitioning that
separates the Oracle system, in the root, from the customer system, in the PDB and that
this basic separation allows, in turn many PDBs to be contained in the same CDB. The PDB
is a declarative mechanism to delineate a consolidated application backend.
True within-database virtualization removes the principle drawbacks of schema-based
consolidation: the collision of global names, which means that expensive and risky changes
have to be made to existing application backends before they can co-exist in the same
non-CDB; and the fact that any privileges, and similar powerful privileges, and grants to public,
span all application backends in a non-CDB.
It is the physical separation between root and PDB that brings pluggability. And pluggability
brings, effectively, the third generation of Data Pump, via unplug/plug. Further, unplug/plug
between CDBs at different Oracle Database software versions brings a new paradigm for
patching the Oracle version. Pluggability, then, removes these two problems brought by
schema-based consolidation: difficulty of provisioning (i.e. moving an application backend
from place to place, and cloning it) and the fact that patching the Oracle version for a single
application backend, when circumstances mandate this, is impossible without, at the same
time, affecting other application backends that are not ready for this change in environment.
We have seen, too, that the sharing model for the SGA and the backround processes is
essentially the same for PDB-based consolidation as for schema-based consolidation and
so the high consolidation density benefit of the older approach is retained in full. Moreover,
the logical virtualization, within the SGA (carried via the data block into the datafiles), the
redo, and the undo brings new powers for within-CDB, between-PDBs, resource
management and allows PDB point-in-time-recovery.
Finally, its tempting to say that CDB is to PDB as operating system is to non-CDB. And the
PDB/non-CDB compatibility guarantee means that the new phenomenon that characterizes
the multitenant architecture is the root. Just as various operating system primitives orchestrate
provisioning tasks, and other maintenance tasks for non-CDBs, SQL statements, executed
against the root implement the corresponding tasks for PDBs. This, in turn, means that
PL/SQL, famously platform independent and portable, available, of course, wherever
Oracle Database is available, and known by all database administrators, is the language of
automation for operations on PDBs.
Oracle Multitenant represents, therefore, the next generation of consolidation for application
backends. It delivers the manage-as-one benefits that adopters of schema-based consolidation
had hoped to win. Adopting it is a pure deployment choice: neither the application backend,
nor the client code, needs to be change
--------------------------------------------------------------
12 Приложение A:
-- Обработка мультиарендной архитектуры в библиотеке документации по СУБД Oracle
Appendix A:
The treatment of the multitenant architecture in the
Oracle Database Documentation Library
For an introduction and overview, start with the Concepts book. This has a new main section,
Multitenant Architecture.
The main coverage is in the Administrators Guide. This, too, has a new main section,
Managing a Multitenant Environment. Of course, because of the PDB/non-CDB compatibility
guarantee, the Database Development Guide needs no more than a passing mention of the
multitenant architecture. (The scope of an edition is the PDB in which it is defined. This
means that many concurrent EBR exercises can be conducted in a single CDB. This fact
removes a challenge that customers face, who have used schema-based consolidation to
implement several application backends in the same pre-12.1 database, necessarily a
non-CDB, when more than one of these backends needs to undergo online patching at the
same time.)
The treatment of the new distinction between local users and common users, and of the
scoping of privileges to the current container, and how this leads to new notions for formal
control of the separation of duties between those of the uber database administrator (the
CDB admin) and those of the of application administrator (the PDB admin) is in the Security
Guide. The book also covers another essential concept in this space: container_data views.
The multitenant architecture introduces remarkably few new SQL constructs. They are
limited mainly to implementing the operations on PDBs as entities. The formal definitions of
the syntax and semantics for these is in the SQL Language Reference.
There are a few brand new data dictionary views (for example, DBA_PDBs) and
performance views (for example, v$PDBs). More noticeably, each performance view has a
new Con_ID column the container identifier for the provenance of the facts represented in
such a view. Correspondingly, but using a slightly different model, the set of flavors of
data dictionary view (DBA_, All_, and User_) is extended with the new CDB_ flavor. Each
CDB_ view has a new Con_ID column. The presence of a CDB_ column in a view reflects its
status as a container_data view. The descriptions of all the views are in the Database Reference.
|
