Oracle Database 12.2: Gestión de memoria a nivel PDB en ambientes multitenant

Artículo publicado en Oracle Technology Network (OTN) en español -  mayo de 2018 

Introducción

En Oracle Database 12.1 un CDB (“Container Database”) tiene una única asignación de memoria SGA (“System Global Area”), la cual es compartida por todos los contenedores, el root container y todas las PDBs.

Lo mismo ocurre con la PGA (“Program Global Area”), donde el parámetro PGA_AGGREGATE_TARGET especifica el objetivo de memoria “target” para la PGA compartida por todos los “server process” conectados a la instancia.

Gran parte de la SGA actúa como una memoria cache que favorece a los objetos accedidos con mayor frecuencia, esto ocurre por ejemplo con el “data buffer cache”, la “shared pool”  y otras estructuras de memoria. Se dá entonces una suerte de competencia entre las distintas sesiones y procesos por la utilización de este espacio en la SGA y sus distintas estructuras asociadas.  Por tal motivo, en versión 12.1 es probable que una PDB con mucha actividad, pueda llegar a tener un dominio claramente marcado en la utilización del espacio de SGA, generando problemas de performance en otras PDBs.

Algo similar a lo anteriormente comentado, ocurre con la utilización de la PGA.

En Oracle Database 12.2 se introduce una nueva manera de gestionar la memoria permitiendo que tanto la SGA como la PGA puedan ser controladas a nivel PDB.

Oracle Database 12.2: Acceso con EM Express a múltiples PDBs utilizando un único puerto

Una de las mejoras introducidas en Oracle Enterprise Manager Database Express ("EM Express") a partir de 12.2, particularmente para ambientes multitenant,  es la posibilidad de utilizar un único puerto o URL para acceder a cualquiera de las PDBs dentro de un CDB.

Cuando realizamos un inicio de sesión en "EM Express",  ahora podemos especificar  el nombre de una “pluggable database” lo cual nos permite ingresar directamente a la misma. El principal beneficio de esta nueva opción, es no tener que configurar más un puerto diferente por cada una de las PDB de la base de datos. En el caso que no indiquemos ninguna PDB durante el "logging", entraremos directamente al root container.

Veamos como funciona:

Usamos para ejemplificar un CDB (cdb12cr2) con una PDB (pdb12cr2) a la cual accederemos por "EM Express".

1) Primero identificamos el puerto utilizado por "EM Express" y verificamos el acceso “default” luego de la creación de una base.

Por defecto, el uso de esta nueva característica (único puerto para acceder a las "pluggables databases") viene deshabilitado. Por lo tanto no podremos acceder a la PDB hasta que no lo habilitemos.

Veamos qué pasa entonces cuando el acceso está deshabilitado e intentamos ingresar a la consola.

Como primer paso averiguamos cual es el puerto que está utilizando "EM Express". La URL de acceso tendrá la siguiente forma:

https://{database-hostname}:{portnumber}/em/

Para obtener el puerto utilizamos la siguiente consulta:

SQL> select dbms_xdb_config.gethttpsport() from dual;

DBMS_XDB_CONFIG.GETHTTPSPORT()

------------------------------

                          5500

Parámetros de inicio en 12c cuando se utiliza arquitectura de bases de datos CDB/PDB (multitenant)

A text initialization parameter file (PFILE) cannot contain PDB-specific parameter values. 

A CDB uses an inheritance model for initialization parameters in which PDBs inherit initialization parameter values from the root. In this case, inheritance means that the value of a particular parameter in the root applies to a particular PDB.

A PDB can override the root's setting for some parameters, which means that a PDB has an inheritance property for each initialization parameter that is either true or false. The inheritance property is true for a parameter when the PDB inherits the root's value for the parameter. The inheritance property is false for a parameter when the PDB does not inherit the root's value for the parameter.

The inheritance property for some parameters must be true. For other parameters, you can change the inheritance property by running theALTER SYSTEM SET statement to set the parameter when the current container is the PDB. If ISPDB_MODIFIABLE is TRUE for an initialization parameter in the V$SYSTEM_PARAMETER view, then the inheritance property can be false for the parameter. When the current container is the root, the CONTAINER clause of the ALTER SYSTEM SET statement controls which PDBs inherit the parameter value being set.

Oracle Multitenant Database Users

Oracle Multitenant, una opción de Oracle Database 12c, incluye tanto usuarios "common" como "local". Un usuario "common"  se crea en la base de datos "container" (CDB) y tiene el mismo nombre de usuario y contraseña en todas las PDB(pluggable databases) que forman parte de esa CDB.  
Los usuario "common" pueden tener privilegios que se otorgan a nivel de contenedor y otros privilegios que se conceden en cada una de las bases "pluggable". Los privilegios pueden ser diferentes en cada una de las PDB, pero el usuario no necesita ser creado de manera individual en cada una de ellas.
Para crear un "common user" para la CDB y todas las PDB, iniciamos sesión en la base de datos contenedor como SYSTEM y creamos un usuario con CONTAINER = ALL.
Debemos tener en cuenta que todos los nombres de usuario "common" tienen que comenzar con el prefijo C##.

SQLPLUS> CONNECT SYSTEM@root
Enter password: **********
Connected.
SQLPLUS> CREATE USER C##DB_ADMIN
IDENTIFIED BY IronMan4
CONTAINER = ALL;

Oracle Multitenant (White Paper)

Oracle White Paper
Oracle Multitenant 

Executive Overview
Oracle Multitenant is a new option for Oracle Database 12c Enterprise Edition that helps customers reduce IT costs by simplifying consolidation, provisioning, upgrades, and more. It is supported by a new architecture that allows a container database to hold many pluggable databases. And it fully complements other options, including Oracle Real Application Clusters and Oracle Active Data Guard. An existing database can be simply adopted, with no change, as a pluggable database; and no changes are needed in the other tiers of the application. The benefits of Oracle Multitenant are brought by implementing a pure deployment choice. The following list calls out the most compelling examples.

• High consolidation density. The many pluggable databases in a single container database share its memory and background processes, letting you operate many more pluggable databases on a particular platform than you can single databases that use the old architecture. This is the same benefit that schema-based consolidation brings. But there are significant barriers to adopting schema-based consolidation, and it causes ongoing operating problems. The new architecture removes these adoption barriers and operating problems.
• Rapid provisioning and cloning using SQL. A pluggable database can be unplugged from one container database and plugged into another. Alternatively, you can clone one, within the same container database, or from one container database to another. These operations, together with creating a pluggable database, are done with new SQL commands and take just seconds. When the underlying filesystem supports thin provisioning, many terabytes can be cloned almost instantaneously simply by using the keyword snapshot in the SQL command.
• New paradigms for rapid patching and upgrades. The investment of time and effort topatch one container database results in patching all of its many pluggable databases. Topatch a single pluggable database, you simply unplug/plug to a container database at adifferent Oracle Database software version.
• Manage many databases as one. By consolidating existing databases as pluggable databases, administrators can manage many databases as one. For example, tasks like backup and disaster recovery are performed at the container database level.
• Dynamic between-pluggable database resource management. Oracle Database 12c Resource Manager is extended with specific functionality to instantly control the competition between the pluggable databases within a container database. This whitepaper explains the new Oracle Database architecture, the new functionality that this brings, and the benefits that ensue. 

http://www.oracle.com/technetwork/database/multitenant-wp-12c-1949736.pdf

Oracle Database 12c: Full Transportable Export/Import

Introduction

Oracle Database 12c includes significant new features such as the Oracle Multitenant Option.
This multitenant architecture includes the ability to create pluggable databases (PDBs), a new way to consolidate multiple databases into a single multitenant container database (CDB).
Many customers will look forward to saving on database management costs, achieving more efficient hardware utilization, and realizing economies of scale by migrating to a consolidated database environment using pluggable databases.
Traditional methods used for database migration work seamlessly with pluggable databases.
Original Export/Import, Data Pump export/import, and transportable tablespaces can all be
used to migrate from earlier versions of Oracle Database to a pluggable database running with Oracle Database 12c. In addition, an exciting new feature, full transportable export/import, is available to make migration to Oracle Database 12c faster, easier, and more efficient than ever before.
This white paper describes the full transportable export/import feature in Oracle Database 12c. After giving an overview of the benefits of using full transportable export/import, it explains how the feature works and provides a detailed example of full transportable export/import to show the syntax and process flow of using this feature. Note that, while this white paper focuses on the use of full transportable export/import in a pluggable database environment, this feature can be used generally for migrations to a Oracle Database 12c non-CDB database as well. 

http://www.oracle.com/technetwork/database/enterprise-edition/full-transportable-wp-12c-1973971.pdf