Problemas con optachauto y resolucion de nombres (error code 238)

Posted on por
Responder

Hoy vamos a ver una entrada rápida

Recientemente me he encontrado con el error code 238 intentando llevar a cabo la aplicación de un parche con el optachauto.

Al intentar llevar a cabo el parcheado me devolvía el siguiente error:

root:$GRID_HOME/OPatch/opatchauto apply $PARCHES/26610308 
OPatchauto session is initiated at Sun Nov 18 15:56:14 2017 

Patch version not found


OPatchauto session completed atSun Nov 18 15:56:20 2017 
Time taken to complete the session 0 minute, 7 seconds 

opatchauto bootstrapping failed with error code 238.

La primera conclusion que debemos de sacar de esto. siempre hay que hacer el analize antes de la aplicacion, ya que de esa manera habríamos comprobado el error .

Tras mucho buscar en la web de soporte y abrir un caso con Oracle, encontramos el problema.

El fichero /etc/hosts de mi servidor tenia mas de dos entradas, supongamos que fuese algo similar a:


10.0.0.1  SERVER server server.dominio  server-vip.dominio

Si desde el sistema operativo preguntábamos por cualquiera de las 4 entradas, el servidor funcionaba correctamente.

Sin embargo, al cambiar esa linea por


10.0.0.1  server server.dominio
10.0.0.1  SERVER  SERVER.dominio 
10.0.0.1  serve-vip  server-vip.dominio

Todo volvió a funcionar a la perfeccion.

Un expediente X que nos sirve para recordar que no todo vale a la hora de solcitar las instalaciones a los equipos responsables de los sistemas operativos, las nuevas herramientas de gestion de los componentes de oracle (opatchauto,datapatch …) son muy potentes, pero no dejan de ser componentes externos a la base de datos que requieren de configuraciones correctas que, desgraciadamente no suelen estar tan documentadas como los prerrequisitos del GRID, RAC o Base de datos, por lo que siempre deberemos de velar por que los sistemas operativos donde se encuentran nuestros motores esten prefectametne configurados

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!