Archivo de la etiqueta: 12c

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

Asignar un EM Express para un PDB específico

Posted on por
Responder

Vamos a seguir viendo pequeñas entradas sencillas sobre aspectos básicos de las PDB y las 12c . En este caso veremos como habilitar el EMexprss para un PDB específico.

En la entrada Donde está la consola en la 12c? vimos que en la version 12c había desaparecido el EM console tal y como lo conocíamos, habiendo sido substituido por una version mucho mas ligera integrada en la propia base de datos y que funciona mediante XMLdb.

Hasta el momento, teníamos acceso a este EMXpress , hemos visto como Dar permisos solo lectura a un usuario del EM express, pero estábamos dando acceso a todo el CDB , algo que seguramente no queramos hacer.

Como habilitamos el acceso a un único PDB

La respuesta es tremendamente sencilla, solamente hay que logarse a este pDB y asignarle un puerto libre a el EM express.
Veamos la secuencia de comandos:



SQL> SHOW CON_NAME
CON_NAME 
------------------------------
CDB$ROOT

SQL> ALTER SESSION SET container = test1;

Session alterado.


SQL> select dbms_xdb_config.gethttpsport () from dual;

DBMS_XDB_CONFIG.GETHTTPSPORT()
------------------------------
                             0

SQL> exec dbms_xdb_config.Sethttpsport (5501);
Procedimiento PL/SQL terminado correctamente.
SQL>

Si ejecutamos el comando DBMS_XDB_CONFIG.GETHTTPSPORT dentro de un PDB veremos que no aparece ningún puerto configurado, esto es por que por defecto el EM solamente está configurado en el CBD principal. Como vemos en los comandos, simplemente asignando un puerto con dbms_xdb_config.Sethttpsport obtenemos en el puerto elegido la consola del EM Express dedicada unidamente a este PDB

A pesar de que nos hemos logrado con SYS, que es un usuario global del CDB, en el puerto 5501 solamente podemos acceder al PDB TEST1

Trucos para crear un dataguard standby

Posted on por
Responder

Si consultamos la documentación de Oracle la creación de un datagurard es algo facilísimo, pero a la hora de la verdad, siempre hay pequeños flecos de configuración antes de la creación que es lo que nos puede traer de cabeza, vamos a ver en esta entrada algunos puntos que mirar antes de empezar para que todo funcione.

Suponemos que :

  • EL SID de la base de datos va a ser cdbtest
  • A la base de datos primaria la llamaremos primary , su nombre único será cdbtest
  • A la base de datos standby la llamaremos standby ,su nombre único será cdbtest_sdby

Pasos a llevar a cabo en primary

Se gun la documentación de Oracle, debería de bastar con:

, pero siempre hay cosas que podemos ir haciendo para que todo vaya a la primera

Activar el standby file management

Mediante esta opción los cambios que llevemos a cabo en la primary database se llevaran a cabo en la standby

alter system set STANDBY_FILE_MANAGEMENT=AUTO ;

Crear grupos de standby redo logs

Estos grupos serán necesarios en standby, si los tenemos creados en primary ademas solucionaremos antes de que ocurran los problemas en caso de switchover.

La sintaxis es igual que la de la creación de un grupo normal añadiendo standby 

alter database add standby logfile group 4  '/u01/app/oracle/oradata/cdbtest/standby_redo04.log' size 52428800;

Hay que crear un grupo de standby redo log file mas que los grupos de redo logs normales.

Configurar el tnsnames del servidor

Este es uno de los puntos importantes, el servidor debe de ser capaz de acceder por oraclenet al standby.
Dado que los dos SID van a ser iguales, aconsejamos el poner una entrada clara en el listener.ora, en nuestro caso los llamaremos exactamente igual que el DB_UNIQU_NAME que es CDBTEST_STDBY 

CDBTEST_STANDBY =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = standby.pamplona.name)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = cdbtest)
    )
  )

Además de esta entrada, deberá de haber una entrada para el LOCAL_LISTENER,la teoría indica que esto ya debería de estar configurado, pero la realidad a veces es distinta, por lo que nos aseguraremos que la variable LOCAL_LISTENER de nuestra base de datos este correctamente configurada y tenga su entrada en el nsnames.ora . 


LISTENER_CDBTEST =
  (ADDRESS = (PROTOCOL = TCP)(HOST = alone.pamplona.name)(PORT = 1521))

Configurar parametros en spfile

Antes de proseguir, es obligatorio el uso de spfile , la creación de la replica va a ser mediante RMAN, por lo que, en caso de usar file fallaría la creación del spfile en standby

Los parámetros que hemos de poner son:

DB_UNIQUE_NAME

Este parámetro no es obligatorio en el primary, pero es recomendable, por lo que lo pondremos 

alter system set db_unique_name='cdbtest' scope=spfile sid='*';

LOG_ARCHIVE_CONFIG

LOG_ARCHIVE_CONFIG habilita o deshabita la recepcion/envio de los redo, pero lo que realmente nos interesa es que especifica para cada una de las bases de datos del Dataguard los nombres únicos de las mismas (DB_UNIQUE_NAME)

alter system LOG_ARCHIVE_CONFIG='DG_CONFIG=(cdbtest,cdbtest_stby)'

LOG_ARCHIVE_DEST_X

Otro de los valores que cambiaremos es la ubicación de los redo logs, aquí indicaremos donde va el primary y el standby, así como los casos.

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1= 'LOCATION=/u01/app/oracle/oradata/cdbtest/archivelog
  VALID_FOR=(ALL_LOGFILES,ALL_ROLES)';
ALTER SYSTEM SET log_archive_dest_2='service=CDBTEST_STANDBY ASYNC NOAFFIRM delay=0 optional compression=disable max_failure=0 max_connections=1 reopen=300 net_timeout=30 DB_UNIQUE_NAME=cdbtest_sdby valid_for=(online_logfile,all_roles)' ;

Configuraciones en el servidor de Standby

Estas configuraciones son seguramente las que mas nos hagan fallar en el proceso, ya que en muchos documentos se dejan como algo que se asume ya está.
Las configuraciones son:

Configuraciones de tnsnames.ora

Este es posiblemente el fichero que vaya a marcar el éxito de nuestra acción a la primera, deberá de contar con las lineas:

  • LOCAL_LISTENER deberemos de tener una entrada distinta a la de producción que fijaremos en la BBDD standby
  • BBDD primaria debemos de tener una entrada que apunte a la BBDD primaria
  • BBDD standbydebemos de tener una entrada que apunte a la BBDD standby

LISTENER_CDBTEST_STANDBY =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby.pamplona.name)(PORT = 1521))

CDBTEST_PRIMARY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = alone.pamplona.name)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = cdbtest)
)
)

CDBTEST,CDBTEST_STANDBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby.pamplona.name)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = cdbtest)
)
)

IMPORTANTE:Si miramos con atención el código que hemos puesto, veremos como el truco es que en el nodo standby la conexión a cdbtest será a si mismo, denotando el primario con otro nombre.

Configuraciones estática del listener

Además de la configuración standard del Listener, deberemos de definir una linea estática con la definición del standby.

# Configuracion estatica para el Dataguard
SID_LIST_LISTENER=
  (SID_LIST=
    (SID_DESC= (DB_UNIQUE_NAME=cdbtest_sandby) (ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1) 
(SID_NAME=cdbtest))

Si no tenemos esta opción, al intentar conectar con el rman obtendremos el error

RMAN-04006: error from auxiliary database: ORA-12528: TNS:listener: all appropriate instances are blocking new connections

Creación de las rutas físicas de la BBDD

En el caso como es el del ejemplo que haya rutas físicas para los datafiles, deberán de estar creadas en el servidor de standby con los permisos necesarios.

Copiado de fichero init.ora

Aunque hemos dicho que es necesario que la base de datos primaria necesitaba de un fichero sprite, para poder arrancar nuestra base de datos de dataguard , la base de datos standby necesitará un init.ora mínimo para arrancar.
Este init.ora va a ser cambiado por el spfile que recuperaremos de la primary,
Es importante que tengamos:

  • db_name
  • db_unique_name
  • local_listener

El resto como decimos lo eliminará substituirá el proceso.

*.audit_file_dest='/u01/app/oracle/admin/cdbtest/adump'
*.audit_trail='db'
*.compatible='12.1.0.2.0'
*.db_block_size=8192
*.db_domain=''
*.db_name='cdbtest'
*.db_unique_name='cdbtest_sdby'
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=cdbtestXDB)'
*.enable_pluggable_database=true
*.local_listener='LISTENER_CDBTEST_STANDBY'
*.log_archive_config='DG_CONFIG=(cdbtest,cdbtest_sdby)'
*.memory_target=4000m
*.open_cursors=300
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.standby_file_management='AUTO'
*.undo_tablespace='UNDOTBS1'

Creación de fichero de duplicado

Llegamos al punto importante, el fichero de duplicado de aman.
Este proceso que era bastante costoso en las versiones 9 y 10 se ha facilitado muchísimo en la 11 y 12.

El fichero viene a ser algo así 

connect target sys/XXX@cdbtest_primary
connect auxiliary sys/XXX@cdbtest
DUPLICATE TARGET DATABASE
  FOR STANDBY
  FROM ACTIVE DATABASE
  DORECOVER
NOFILENAMECHECK
  SPFILE
	SET db_unique_name="cdbtest_sdby"  comment "Base de datos sandby"
	SET LOCAL_LISTENER="LISTENER_CDBTEST_STANDBY"
	SET standby_file_management='AUTO'
	set log_file_name_convert='/u01/app/oracle/oradata/cdbtest/','/u01/app/oracle/oradata/cdbtest/'

Y los puntos importantes son:

  • NOFILENAMECHECK Esto nos dejará todos los ficheros exactamente como en la primary
  • Apartado set Aqui le decimos lo que va a cambiar del spfile respecto de la original, nosotros cambiamos:
    • db_unique_name. Indicamos el unique name de la standby
    • LOCAL_LISTENER Este es importante para que encuentre el listener de la maquina de la standby
    • log_file_name_convert La teoría indica que no deberíamos de tener que indicar este parámetro, pero en diversas pruebas he tenido problemas con los redo log files, mediante esta cláusula, indicándole el path de los redo log Files por duplicado (para que no cambie nada) los crea correctamente

Duplicacion

Con esto solamente nos queda el proceso de duplicación, que ya es algo tan sencillo como ejecutar en el servidor de standby 

#!/bin/bash
SET ORACLE_SID=cdbtest 
sqlplus "/as sysdba" << EOF
startup nomount;
exit;
EOF
rman cmdfile comandos_rman.cmd

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;