Archivo de la categoría: 12c

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).

errores ORA-16698: en la creación del data guard boker

Posted on por
Responder

Hoy vamos a ver un a entrada rápida y sencilla sobre un error bastante común en la creación de una configuración del dataguard broker.

Supongamos tenemos un dataguard funcionando y que queremos gestionar mediante el dataguard broker.

Nuestros primeros pasos serán intentar crear una configuración con

DGMGRL> create configuration cdbtest_DG as primary database is cdbtest connect identifier is cdbtest ;

Pero recibimos el siguiente error:

ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added

Si nuestro dataguard está funcionando correctamente , y esta aplicando los logs …¿A que es debido?

Si miramos en nuestra base de datos 


SQL> show parameter LOG_ARCHIVE_DEST_2 

NAME			   TYPE	 VALUE
----------------------- ------------------------------
log_archive_dest_2	   string	 service=cdbtest_standby ASYNC
					 NOAFFIRM delay=0 optional comp
					 ression=disable max_failure=0
					 max_connections=1 reopen=300 n
					 et_timeout=30 DB_UNIQUE_NAME=c
					 dbtest_standby valid_for=(onli
					 ne_logfile,all_roles)
log_archive_dest_20		     string

Esto no debería de ser problema, pero la realidad es que si que lo es, y no por un bug, sino por indicación del propio Oracle.
Para poder crear la configuración este parámetro deberá de estar limpio , así pues si lo vaciamos y ejecutamos el comando tendremos que:

SQL> alter system set log_archive_dest_2='';
System altered.
SQL> quit

[oracle@alone creacion_dataguard]$ dgmgrl sys/XX
DGMGRL> create configuration cdbtest_DG as primary database is cdbtest connect identifier  is cdbtest ;
Configuration "cdbtest_dg" created with primary database "cdbtest"
DGMGRL>

Más información en escenarios en la creación de dataguard

Trazando sqlnet en el servidor de Base de datos

Posted on por
Responder

Hoy veremos una entrada sobre diagnósticos de la base de datos.

Supongamos que tenemos algún tipo de error entre cliente y servidor en la capa OCI, la accion lógica en estos casos es activar una traza del sqlnet para detectar donde se encuentra el problema.
Si seguimos la nota de Oracle SQL*Net & Oracle Net Services – Tracing and Logging at a Glance (Doc ID 219968.1) veremos como , con las siguientes líneas deberíamos de tener en el directorio /home/oracle/trazas_problema_sqlnet una traza por cada uno de los procesos de conexion a la base de datos.

trace_level_server = 6
trace_file_server = svr
trace_directory_server = /home/oracle/trazas_problema_sqlnet
trace_unique_server = on
trace_timestamp_server = on
log_file_server = svr
log_directory_server = /home/oracle/trazas_problema_sqlnet

Sin embargo, cuando añadimos nuestros parámetros de traza vemos que en el directorio que hemos marcado para las trazas no aparece ningún fichero.
¿Que ocurre?

¿por que ocurre esto?

Si miramos la documentacion del sqlnet en https://docs.oracle.com/cd/B28359_01/network.111/b28317/sqlnet.htm#NETRF419

vemos como desde la version 11 en adelante tenemos los parámetros que funcionan con el ADDR-DIAG habilitado y los que funcionan cuando esta deshabilitado.
En nuestro caso, el problema es que al estar habilitado por defecto el diagnistico unificado de Oracle, no está haciendo caso a nuestras directrices.

¿Como lo solucionamos

La solución no puede ser mas sencilla, simplemente deberemos de decirle en el mismo sqlnet.ora que no use el diagnostico unificado de Oracle, esto lo haremos añadiendo la línea

DIAG_ADR_ENABLED = OFF

Con esto comenzará a trazar en la ubicación designada.

NOTA:
Debemos de recordar eliminar esta línea cuando acabemos de trazar ya que, ademas de poder llenar el filesystem por la traza, estamos indicando al servidor que no use el DIAG_ADR algo que no es conveniente .

Como siempre mas información en :

  • SQL*Net & Oracle Net Services – Tracing and Logging at a Glance (Doc ID 219968.1)
  • documentacion de Sqlnet

Obtener los parches instalados en la base de datos /CBD

Posted on por
Responder

Hoy vamos a ver una entrada muy rápida saber como ver el nivel de parcheado de una máquina.

Con el nuevo modelo de datapatch y los pdb/cbd la propia base de datos /contenedor necesita saber en que nivel de parcheado se encuentra, para ello tenemos un nuevo conjunto de librerías en el paquete DBMS_QOPATCH que informan de los parches que se han aplicado en la base de datos.
En nuestro caso, vamos a ver la llamada dbms_qopatch.get_sqlpatch_status;

[oracle@TEST] $ sqlplus "/as sysdba"
SQL*Plus: Release 12.1.0.2.0 Production on Fri Jun 16 16:54:59 2017
SQL>  set serverout on
SQL> exec dbms_qopatch.get_sqlpatch_status;

Patch Id : 25171037
        Action : APPLY
        Action Time : 14-JUN-2017 23:09:33
        Description : DATABASE PATCH SET UPDATE 12.1.0.2.170418
        Logfile :
/u01/app/oracle/cfgtoollogs/sqlpatch/25171037/21099266/25171037_apply_SID_2017Jun14_23_09_20.log
        Status : SUCCESS
PL/SQL procedure successfully completed.

Aquí podemos ver como , a esta base de datos sele ha aplicado el PATCH SET UPDATE 12.1.0.2.170418
Pero puede darse el caso de que , se aplique un parche sobre la infraestructura, o sobre los binarios sin aplicarse sobre el motor.

IMPORTANTE

Así pues recordar que , ahora, deberemos de mirar

  • Opatch lsinventory para ver el nivel de parcheado del motor
  • bms_qopatch.get_sqlpatch_status Para ver los parches aplicados sobre tu cbd o base de datos

Informacion en el arranque

“Dumping current patch information” in Alert Log 12c can lead to a misinterpretation

Error en el Opacth «Java (1.6) could not be located. OPatch cannot proceed!»

Posted on por
Responder

Hoy vamos a ver una solución rápida para un error común.

Cuando actualizamos el Opatch de la base de datos al ultimo OPatch(versión 6880880) podemos encontrarnos con que el binario no detecte el Java

-bash-4.2$ ./opatch lsinventory
Java (1.6) could not be located. OPatch cannot proceed!
OPatch returns with error code = 1

La solución es muy sencilla la propia instalación de binarios de Oracle cuenta con un jdk que es válido para la ejecución del Opatch, así que solamente tendremos que indicarle al Opatch donde esta esta ruta. Para ello usaremos el flag -jdk en el que le diremos que puede usar el propio $ORACLE_HOME/jdk

-bash-4.2$ ./opatch lsinventory -jdk $ORACLE_HOME/jdk
Oracle Interim Patch Installer version 12.2.0.1.9
Copyright (c) 2017, Oracle Corporation.  All rights reserved.
Oracle Home       : /opt/app/oracle/product/12.1.0/db_1
Central Inventory : /opt/app/oraInventory
   from           : /opt/app/oracle/product/12.1.0/db_1/oraInst.loc
OPatch version    : 12.2.0.1.9
OUI version       : 12.1.0.2.0
Log file location : /opt/app/oracle/product/12.1.0/db_1/cfgtoollogs/opatch/opatch2017-06-12_19_10-54PM_1.log
Lsinventory Output file location : /opt/app/oracle/product/12.1.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory2017-06-12_19_10-54PM.txt
--------------------------------------------------------------------------------
Local Machine Information::
Hostname: PRUEBAS
ARU platform id: 226
ARU platform description:: Linux x86-64
Installed Top-level Products (1):
Oracle Database 12c                                                  12.1.0.2.0
There are 1 products installed in this Oracle Home.
There are no Interim patches installed in this Oracle Home.
--------------------------------------------------------------------------------
OPatch succeeded.

Como veis, una solución sencilla que nos evitará tener que lidiar con los distintos JAVA instalados en el servidor.

Como siempre, mas información en :

  • Descargar el ultimo opatch (6880880) Versión (Doc ID 274526.1)
  • Master Note For OPatch (Doc ID 293369.1)