Archivo del Autor: admin

Acerca de admin

Tras más de 20 años trabajando con tecnologías Oracle, me decidí a recopilar en un Blog algunas de las cosillas útiles para el día a día.

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

deshabitando IP6 en Oracle Linux

Posted on por
Responder

Hoy vamos a ver una entrada rápida para dummies. Como deshabilitar el IPV6

El IPv6 es algo que seguramente no estemos usando y puede llegar a molestarnos tener activado, no es algo que deba de darnos errores, pero si que introduce ruido en el sistema, que es algo que no deseamos, así pues, vamos a ver de manera sencilla como quitarlo.

cambios en /etc/sysctl.conf

En el fichero de control del sistema añadiremos las siguientes entradas 

# Deshabilitamos  IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Deshabilitamos de las interfaces

El siguiente paso es deshabilitarlo de las interfaces, para ello iremos al directorio /etc/sysconfig/network-scripts/ y para cada uno de los ficheros ifcfg- configuraremos la línea:

IPV6INIT=no

Deshabilitamos en el grub

En la parte de GRUB_CMDLINE_LINUX añadiremos también el comando para que no lo lance al inicio, así pues, añadiremos al fichero /etc/default/grub lo siguiente 

ipv6.disable=1

y regeneramos el grub con 

grub2-mkconfig -o /boot/grub2/grub.cfg

Tras esto reiniciamos el sistema, y ya estaremos libres de IPV6

Actualizacion
Parece ser que podemos encontrar problemas con el ssh y las X en Oracle Linux 7 .
Para solucionarlo, tendremos que ir al fichero /etc/ssh/sshd_config y modificar 

#AddressFamily any

AddressFamily inet

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