Archivo de la categoría: Oracle

Entradas sobre bases de datos Oracle

Checklist de informacion sobre tablespaces en 12c con CDB/PDB

Posted on por
Responder

Vamos a ver una serie de entradas rápidas a modo de resumen sobre la version 12c

Administrar tablespaces en CDB/PDB

En general los tablespaces se gestionan de la misma manera que en las non-cdb-database, sin embargo hay algunas consideraciones para los tablespaces en los CBD

  • Un tablespace permanente solamente puede estar asociado a un contenedor (PDB)
  • Los tablespaces en un PDB se crean solo desde ese pdb
  • Cada PDB deberá de tener su propio default tablespace
  • Si un tablespace es creado en un contenedor (PDB), el tablespace se asocia directamente a este contenedor
  • Un CDB (o cada instancia de un CDB en RAC ) solamente puede tener activo un Undotablespace
  • Solamente hay un tablespace temporal (o un grupo temporal) para un CDB, el root usa este temporal, los PDB pueden usar este o crearse su propio temporarytablespace. Cuando un PDB se desconecta del CDB sus temporales también se desconectan con el .
  • Cuando un usuario entre a un PDB y su tablespace por defecto no esté asociado a este PDB automáticamente se le asociará al usuario el tablespace por defecto del PDB
  • El UNDO tablespace es común, al contrario que ocurre con el temporal un PDB no puede tener un tablespace UNDO especifico para el.
  • Todos los PDB tienen su propio tablespace SYSTEM y SYSAUX, pero este tablespaceactua como un subconjunto del del ROOT$CDB,en estos tablespaces solamente se guardará información relativa a estos solo guardan los metadatos de usuario, los metadatos de Oracle están guardados en el el CDB.

Tablespace por defecto

  • Cada PDB debe de tener un tablespace por defecto.
  • Si ejecutas un ALTER DATABASE DEFAULT TABLESPACE XX; en el CDB$ROOT lo que estás cambiando es el del CDB$ROOT, para cambiar el default tablespace en uno de los PDBs has d ejecutar
    ALTER PLUGGABLE DATABASE DEFAULT TABLESPACE XX;

Administrar tablespaces temporales

Como indicábamos arriba,solamente hay un tablespace temporal (o un grupo temporal) para un CDB, el root usa este temporal, los PDB pueden usar este o crearse su propio temporarytablespace. Cuando un PDB se desconecta del CDB sus temporales también se desconectan con el.

Introdución a ILM

Posted on por
Responder

Hoy vamos a ver una pequeña entrada para dumies que sirva de introducción a el ILM

el ILM (information cycle managemet) no es otra cosa que, como se deduce de la traducción del inglés la administración del ciclo de vida de la información, lo que en términos llanos sería el gestionar que hacemos cuando la información crece.

Oracle 12c dispone de dos mecanismos combinados que aportan muchísima potencia para tratar con este tema de arquitecturas, si queréis adentraros mas en este tipo de informacion, deberéis de buscarla en las guías de VLDB (Very Large Databases),pero aqui veremos muy por encima estos dos componentes para , al menos ser conocedores de que existen.
Estos dos componentes solo están soportados en cdb y pdb desde la 12.2

Componentes básicos de ILM

Heat Map

El HEAT MAP recopila en la vista V$HEAT_MAP_SEGMENT información en tiempo real tanto de DML como de acceso a los segmentos de los tablespaces de la base de datos. Esta información la obtiene directamente desde la memoria y es bajada regularmente mediante jobs del scheduler a las tablas que encuentran en SYSAUX.
Se activa mediante el parámetro

 ALTER SYSTEM SET HEAT_MAP=[ON|OFF]

Algo curioso es que se puede activar también a nivel de sesión.

El Heat Map es capaz de trazar la información de uso a nivel de fila y segmento, pero es una funcionalidad enfocada a tratar datos de negocio, por lo que no registra lo que ocurre en SYSTEM o SYSAUX.

Heat Map registra los datos de la siguiente manera:
• Los cambios que hacen modificaciones son registrados a nivel de fila y transmitidos a nivel de bloque.
• Los cambios a nivel de acceso son registrados a nivel de segmento.

ADO (Automatic Data Optimization)

ADO es el segundo componente que vamos a ver hoy, este componente permite a los administradores a crear políticas para hacer compresión y movimiento de datos.

Cuando creas una política la base de datos evalua periodicamente la política y lleva a cabo las tareas necesarias.(también pueden lanzarse a mano)
Las políticas de ADO se pueden especificar a nivel de segmento o fila tanto para tablas como para particiones
importante:Esta funcionalidad necesita de Oracle Advanced Compresion, por lo que es una funcionalidad que requiere de licenciamiento específico

Generando políticas de ILM

Una vez sabemos que podemos trazar la vida de los datos, y que podemos crear políticas que lo gestionen, es cuando llegamos a ver la verdadera potencia de esta funcionalidad.
Vamos a ver dos tipos de políticas bien diferenciados
• políticas que compresión
• políticas de movimiento de datos

Políticas de compresión

Las políticas de compresión cuentan con 4 parámetros
• Nivel tablespace,tabla,partición
• Tipo de Compresion
• Ámbito (cuando hacerlo)
• Clausula temporal

Tipos de compresion

Podemos contar con 4 tipos distintos de compresión.

  • ROW STORE COMPRESS BASIC: Es el básico que se usa al insertar en una tabla usando “advanced compression» (ACO) si no usas directpath, para estas se usa la cláusula ROW STORE COMPRESS BASIC.
  • ROW STORE COMPRESS ADVANCED: En versiones anteriores se llamaba OLTP compression y ha sido renombrado, hace compresión standard para indices y LOW para lob segments .
  • COLUMN STORE COMPRESS FOR QUERY LOW or HIGH: Provee Hybrid columnar compression ( HCC) y mayor grado de compression que el anterior.
    Esta no se puede aplicar a nivel ROW. Funciona bien para entornos donde el rendimiento es crítico y tenemos muchas consultas pero se esperan pocas acciones de DML.
    La compresión de los LOBS es MEDIUM.

  • COLUMN STORE COMPRESS FOR ARCHIVE LOW or HIGH: Provee de Hybrid columnar compression (or HCC) y del máximo nivel de compresion, es conveniente cuando el acceso a los datos es bajo y no se espera ninguna DML.
    Hace COLUMN STORE COMPRESS FOR ARCHIVE LOW or HIGH maps to MEDIUM compression for SecureFile LOB segments . Esta no se puede aplicar a nivel ROW

Los datos pueden ser comprimidos cuando son insertados, actualizados o cargados en una tabla desde un bulk load.

Ambito de la compresion

  • ROW: Se pueden crear basadas en fecha de modificacion
  • SEGMENT:se pueden aplicar a tablas o particiones
  • Group: Si una tabla es elegible para compresión esta compresión se aplica a todos los objetos dependientes ( Lobs,global indexes..) .Solo se aplica a tipo de segmento
  • Tablespace: Se aplica a todos los segmentos del tablespace

Ejemplos

La manera mas sencilla de verlo es viendo algunos ejemplos
Ejemplo de política aplicado a una particion sobre fila (row level compresion después de 90 días)

ALTER TABLE libros  MODIFY PARTITION narrativa 
  ILM ADD POLICY ROW STORE COMPRESS ADVANCED
 ROW 
  AFTER 90 DAYS OF NO MODIFICATION;

Ejemplo de política aplicada a nivel tablespace aplicado a a nivel segmento.

ALTER TABLESPACE DATOS1 DEFAULT
ILM ADD POLICY  ROW STORE COMPRESS ADVANCED
 SEGMENT 
AFTER 30 DAYS OF NO ACCESS;

Ejemplo de política de HCC sobre una partición a nivel segmento

ALTER TABLE libros  MODIFY PARTITION ficcion 
  ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH 
SEGMENT 
  AFTER 12 MONTHS OF NO MODIFICATION;

Políticas de movimientos de datos

Al contrario de las políticas de compresión que pueden llevarse a cabo a nivel de fila o segmento , las de movimiento solamente pueden llevarse a cabo a nivel de segmento.Esto se lleva a cabo mediante la cláusula TIER_TO


ALTER TABLE libros MODIFY PARTITION ensayo 
  ILM ADD POLICY
  TIER TO almacenamiento_barato;

¿Cómo sabe la base de datos cuando hacer este movimiento? La base de datos moverá la particion ensayo de la tabla libroscuando llegue al fullnes thresold
Hay dos parámetros que regulan las políticas de movimiento

  • TBS_PERCENT_USED : Se modfica con DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_USED,85)
  • TBS_PERCENT_FREE: Se modfica con DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_FREE,25)

Cuando la partición ensayo de la tabla libros pase el umbral marcado en TBS_PERCENT_USED(85%) de ocupación se moverán los datos menos usados ( mas fríos) segmentos al tablespace almacenamiento_barato, esta operacion se detendrá cuando quede libre el umbral marcado en TBS_PERCENT_FREE, en nuestro caso un 25% libre.

En caso de haber politicas a nivel de tabla y tablespace, la de nivel tabla predomina sobre la de tablespace

Como veis, la combinación de HEAT MAP y ADO es muy potente para gestionar bases de datos muy grandes, permitiéndonos tener los datos mas accedimos el almacenamiento rápido, y los menos accedido en almacenamiento mas barato (aunque posiblemente mas lento)

Más información en la sección de documentación de Very large databases de Oracle

ORA-65092 (nuevos errores de la 12c)

Posted on por
Responder

Tras las vacaciones vamos a ver una entrada rápida y sencilla para «dummies de la 12c»

Como sabemos, la versión 12c con las bases de datos multicontenedoras nos han traído una nueva diferenciación de usuarios de bases de datos, los usuarios globales y los usuarios locales.

A nivel de usuarios locales , apenas cambia nada, pero , cuando hablamos de usuarios y privilegios globales, podemos hacernos un poco de lío.

Supongamos tenemos un sistema con un CDB y multiples PDBs, tenemos un usuario que queremos esté en todas las bases de datos, este usuario pongamos que es el usuario PEPE, y al ser un usuaro global ( está en todos los pdbs) su nombre de esquema será C##PEPE

Si quisiéramos darle el privilegio CREATE TABLE solamente tendríamos que conectarnos al CDB$ROOT y ejecutar 

SQL >GRANT CREATE TABLE TO C##PEPE;

Como veis, no hemos incluido la clausula CONTAINER=ALL por que en este tipo de sentencias es implícita.
Pero, ¿que ocurre si se lo queremos quitar?. Si ahora ejecutamos 

SQL > REVOKE create table FROM C##PEPE;

recibiríamos el error

ORA-65092:system privilege granted with a different scope to C##PEPE

¿Como es posible?

Desafortunadamente vamos a tener que ir acostumbrándonos a este tipo de cosas con la gestion de los usuarios globales, la causa del error es que, al contrario de lo que ocurre cuando das un permiso a un usuario global ( donde la cáusula CONTAINER=ALL es implicita), cuando se los quitas no lo es, por lo que, a no ser que la especifiques manualmente recibiremos el error visto anteriormente.

Para revocar el privilegio solamente habría que hacer:

SQL > REVOKE create table FROM C##PEPE CONTAINER=ALL;

Mas información como siempre en:
Documentación de errores de ORACLE

ORA-16179: incremental changes to “log_archive_dest_1” not allowed with SPFILE

Posted on por
Responder

Vamos a ver una pequeña entrada rápida muy muy de dummie sobre un error ORA-XX

Intentando modificar el parámetro de los archivers de mi CDB de pruebas me encuentro con que, al ejecutar 

alter system set LOG_ARCHIVE_DEST_1 ='LOCATION   =/u01/app/oracle/oradata/cdbtest/archivelog/' scope=both sid='*'

Recibimo el error 

ERROR at line 1:
ORA-32017: failure in updating SPFILE
ORA-16179: incremental changes to "log_archive_dest_1" not allowed with SPFILE

Si miramos la configuración del archivado

SQL>  archive log list
Database log mode	       Archive Mode
Automatic archival	       Enabled
Archive destination	       /u01/app/oracle/product/12.1.0/dbhome_1/dbs/arch
Oldest online log sequence     38
Next log sequence to archive   40
Current log sequence	       40

Después de muchas muchas vueltas, he visto lo sencilla que era la solución .
La cláusula LOCATION de og_archive_dest_1 no puede tener espacios.
Así pues

‘LOCATION = /path/’; -> ERROR
‘LOCATION=/path/’; -> CORRECTO

Como veis, otra de las soluciones sencillas a problemas que pueden traernos de cabeza!

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