Archivo de la categoría: CDB/PDB

Uso del gestor de recursos en un CBD y PDB

Posted on por
Responder

Con la llegada de la 12c se han introducido mejoraras en el manejo de los gestores de recursos, de manera que el Resource Manager puede ser usado a dos niveles:
• CDB: Gestiona los recursos entre los distintos PDB
• PDB: Gestiona los recursos de manera tradicional

Gestión de los recursos en el CDB: Administrando recursos entre los PDBS

Algo que puede parecer evidente pero que debemos de decir, es que esta gestión se lleva a cabo en el CBD$ROOT, No se puede poner recursos al CDB$ROOT, igualmente no aparece en el computo de los shares
El Resource Manager lleva a cabo esta tarea mediante dos conceptos, shares y límites

  • Shares
    Los shares es la manera que tiene de repartir los recursos, a más shares, mas recursos dispone el PDB
    El porcentaje que asigna cada share se obtiene dividiendo el 100% de los recursos entre el numero de shares y multiplicándolo.

  • Limites
    EL otro parámetro que puedes indicar es el límite de utilización sobre el global, este límite puedes aplicarlo solamente a:

    • CPU
    • Cantidad de ejecuciones paralelas en el servidor

[table caption=»Planes de recursos» width=500]
Contenedor,shares,utilization limit, PARALLEL SERVER LIMIT
Default, 1 ,100%, 100%
PDB1 ,4 ,50% , 100%
PDB2 ,1 ,100% ,50%
[/table]

¿Qué significa un valor de 50% en PARALLEL SERVER LIMIT?

El PARALLEL SERVER LIMIT indica un porcentaje, este porcentaje es sobre el valor de inicialización de la base de datos de PARALLEL_SERVERS_TARGET, así pues, si tenemos un valor de 200 en PARALLEL_SERVER_TARGETS tendremos que el PARALLEL_SERVER_LIMITS será de 0.50*200=100 procesos paralelos.

No todos los PDBs tienen por que tener una política de asignación, aquellos que no la tengan irán a parar a el “Default allocation”.
Las directivas sobre los PDBs se han de crear en el momento de CREATE_CDB_PLAN_DIRECTIVE, y un PDB solamente puede ser afectado por una directiva.

¿Cuáles son los parámetros por defecto de la directiva “Default allocation”?

Si no especificas ninguna política específica para un PDB irá a la de por defecto con :
Shares=1
Utilization_limit=100
Parallel_srever_limit=100

Pasos para crear/modificar un plan

Para modificarlos el paquete DMNS_RESOURCE_MANAGER tiene su propia directiva llamada UPDATE_CDB_DEFAULT_DIRECTIVE

Pasos para la creacion

Al igual que en las BBDD clásicas hay que:
1. Crear el pending area
2. Crear el plan
3. Crear directivas (DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE)
4. Validar el pending area
5. Submit el pending area

Habilitar el plan

Al igual que en las versiones antiguas 

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN=’myplan;

Se puede deshabilitar el plan quitando la variable de inicialización

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN=’’;

PDB: Administracion de recursos dentro de los PDB

La administracion de recursos dentro del PDB se lleva a cabo igual que se llevaba dentro de las bases de datos tradicionales, teniendo en cuenta:

  • Ha de ser un single level resource plan, ya no puede ser multilevel
  • Tienes solamente 8 grupos de consumidores ( en el no-cdb son 32)
  • No puedes tener subplans dentro del plan ( en el no-dbs se podia)

Hay que tener en cuenta que hay dos parámetros que cambian de nombre:
MAX_UTILIZATION_LIMIT pasa a ser UTILIZATION_LIMIT
PARALLEL_TARGET_PERCENTAGE pasa a ser PARALLEL_SERVER_LIMIT

Es importante que, para poder crear una politica de gestor de recursos dentro de un PDB,la política del CDB para los recursos que quieres administrar debe de debe de satisfacer :
CPU

  • La directiva debe de tener definido el valor de SHARES para ese PDB
  • La directiva debe de tener definido el valor de UTILIZATION_LIMIT a menos del 100%

PARALLEL EXECUTION

  • Las dos de arriba de CPU
  • La directiva debe de tener definido el valor de PARALLEL_SERVER_LIMIT a menos del 100%

Notas finales del resource manager

Se ha introducido un Nuevo grupo de consumidores llamado LOG_ONLY que sirve para usarlo en como switch group en los casos en los que merely want to log the runaway query but don’t want to change its consumer group or perform any other action
Puedes ver lo definido en las vistas
V$RSRC_PLAN
DBA_CDB_RSRC_PLANS

Otra de las cosas que ofrece el RESOURCE MANAGER es que ha añadido nuevas columnas en la vista V$SQL_MONITOR

  • RM_LAST_ACTION The most recent action taken by the Resource Manager, such as cancelling a SQL execution or killing a session
  • RM_LAST_ACTION_REASON The reason for the most recent action taken by theResource Manager on this SQL operation, such as SWITCH_CPU_TIME orSWITCH_ELAPSED_TIME
  • RM_LAST_ACTION_TIME The time of the most recent action taken by the Resource Manager on this SQL operation
  • RM_CONSUMER_GROUP The current consumer group for this SQL operation

ORA-39866 haciendo flashback con CDB/PDB

Posted on por
Responder

Hoy vamos a seguir viendo pequeñas diferencias entre la 12c y las versiones anteriores.

El funcionamiento del FlashbackDatabase es similar al que tiene la base de datos tradicional(no-cdb) , aunque tenemos que tener en cuenta un punto importante.
No se puede llevar a cabo un flashback de todo un CDB si se ha llevado a cabo un point-in-time recovery de uno de sus PDBs.
El intentar llevar un CBD a un punto anterior a la recuperación de uno de sus PDBs darán el error 

ORA-39866: Data files for Pluggable Database TEST1 must be offline 
to flashback across PDB point-in-time recovery

Si quisieses llevar a cabo el volver el CBD después de haber restaurado un PDB a un punto tendríamos que :

  • Llevar a cabo un backup de todo
  • Parar el PDB
  • Dejar offline todos los ficheros del PDB
  • Hacer flashback del CDB
  • Restaurar el PDB al punto en el que estaba antes del flashback del PDB

Como veis, un cambio muy pequeño, pero que es conveniente conocer para no tener quebraderos de cabeza

Uso de RMAN con PDBs

Posted on por
Responder

Con la llegada de los plugable databases se nos abre un mar de dudas, especialmente en un campo tan delicado como el backup.
Hoy vamos a ver en una entrada muy por encima las opciones de backup que tenemos con la nueva funcionalidad de la 12c

Llevar a cabo backups en CDB/PDB

Igual que las bases de datos no cdv se pueden lanzar desde RMAN y/o Enterprise manager Cloud Control El backup del CDB es igual al de un “no-cdb”, de esta backup de rman podríamos recuperar tanto el CDB completo como alguno de los PDBs del backup

  • Backup completo del CDB: Conectando al cdb y BACKUP DATABASE
  • Backup del PDB root: BACKUP DATABASE ROOT
  • Backup de un PDB:
    • conectando al CDB y BACKUP PLUGGABLE DATABASE test1
    • conectando al CDB y BACKUP PLUGGABLE DATABASE test1,test2,test3
    • Conectando al PDB y ejecutando BACKUP DATABASE

Recuperación de CDB and PDB

A la hora de llevar a cabo una recuperación de la base de datos se puede hacer también el CBD completo, solamente el root o un PDB independiente.
Si en la cadena de conexión del RMAN te conectas al CBD recuperarás todo, si te conectas a un PDB específico será este PDB lo que recuperarás
NOTA:Aunque técnicamente es posible restaurar solamente el root, Oracle recomienda no hacerlo , y si has de restaurar el root restaurar también los PDBs de la base de datos.
Puedes restaurar también un PDB con 

RESTORE PLUGGABLE DATABASE

Mientras estas restaurando un PDB el resto de ellos puede dar servicio normalmente
Los comandos a la hora de restaurar datafiles específicos son como los de no-cbd, pero incluyendo el PLUGGABLE database (al tratarse de un PDB).

Parámetros de inicio en los PDB

Posted on por
Responder

Hoy vamos a ver una entrada muy breve sobre los parámetros de inicio en la nueva versión 12c

Los PDBS no tienen un fichero de inicialización propio, comparten el spfile único del CDB pero algunos de los parámetros de este spfile son modificables a nivel de PDB
La manera de ver cuales son es mediante la consulta 

select name from v$system_parameter where ispdb_modifiable=‘TRUE';

Cada uno de estos (185) son heredados del CDB, y pueden ser modificados mediante .
Si el scoops es SPFILE o BOTH viajarán con la PDB cuando se haga una operación de plug/unplug

Arranque y paradas de los PDB

Posted on por
Responder

Hoy vamos a ver una entrada de iniciación a las bases de datos 12c

Veremos las diferencias y similitudes entre no-cdb y doc

Si no forma parte de un RAC, la mecánica de un DBC es la misma que tenemos en una base de datos normal.
La vista en la que se ve el estado de los PDB es la v$PDBS

SQL> select con_id,DBID,NAME,OPEN_MODE from v$pdbs;
   CON_ID       DBID NAME                           OPEN_MODE 
---------- ---------- ------------------------------ ----------
         2 3975244989 PDB$SEED                       READ ONLY 
         3 2001395940 TEST1                          READ WRITE
         4  810296607 TEST2                          MOUNTED

Estados del CBD

NOMOUNT: Cuando la CBD está en estado nomount los PDB no tienen status, si preguntamos por ellos no tendremos información

SQL> select con_id,DBID,NAME,OPEN_MODE from v$pdbs;
no rows selected

MOUNT:Cuando la CBD está en estado mount los controlfiles de el CDB y PDB ya cuentan con información por lo que los dos están en estado Mount .

  CON_ID	 DBID NAME			     OPEN_MODE

---------- ---------- ------------------------------ ----------
	 2 3975244989 PDB$SEED		             MOUNTED
	 3 2001395940 TEST1			     MOUNTED
	 4  810296607 TEST2			     MOUNTED

OPEN: Con la base de datos abierta la base de datos SEED estará en modo REEAD ONLY, el resto estará en alguno de los estados de los PDB

    CON_ID       DBID NAME                           OPEN_MODE 
    -------- ---------- ------------------------------ ----------
         2 3975244989 PDB$SEED                       READ ONLY 
         3 2001395940 TEST1                          READ WRITE
         4  810296607 TEST2                          MOUNTED

Estados del PDB

Los PDB se administran de manera similar a la base de datos, algunos ejemplos de nuestro caso serían

ALTER PLUGGABLE DATABASE TEST2 OPEN ;  (La abre en modo read write)
ALTER PLUGGABLE DATABASE TEST2,TEST1 OPEN READ ONLY;
ALTER PLUGGABLE DATABASE ALL OPEN ;
ALTER PLUGGABLE DATABASE ALL EXCEPT test2 OPEN ;

Si el contenedor (CDB) es un PHYSYCAL STANDBY entonces el modo open por defecto la deja en modo read only.
Los modos en los que pueden estar los CDB son:

  • OPEN READ WRITE: como el nombre indica abierta lectura escritura (puedes generar redos)
  • OPEN READ ONLY: como el nombre indica abierta lectura escritura
  • OPEN MIGRATE: Este modo permite ejecutar un upgrade del PDB , si desde el root hacer un ALTER DATABASE OPEN UPGRADE el PDB se pone así
  • MOUNTED: Es como una base de datos normal en modo MOUNT , no permite hacer cambios de los objetos y solo es accesible a los administradores
    La parada es igual que el arranque, en este modo de parada tiene mas sentido el de la cláusula EXCEPT

    ALTER PLUGGABLE DATABASE TEST2 CLOSE ;  (La abre en modo read write)
ALTER PLUGGABLE DATABASE TEST2,TEST1 CLOSE ABORT;
ALTER PLUGGABLE DATABASE ALL CLOSE ;
ALTER PLUGGABLE DATABASE ALL EXCEPT test2 CLOSE ;

NOTA: Cuando estas conectado a una pluggable Database el comando SHUTDOWN IMMEDIATE, es el equivalente a si ejecutaras ALTER PLUGGABLE DATABASE CLOSE;