Archivo de la categoría: migracion

ORA-600 en la ejecucion de DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;

Posted on por
Responder

Hoy vamos a ver una sencilla entrada sobre un paso basico en un upgrade de base de datos.

Antes de llevar a cabo un proceso de migracion debemos de asegurarnos que todas las estadisticas de la base de datos estan recientemente recopiladas ( menos de fos dias),

Puede darse el caso de que ejecutando el paquete de obtencion de las estadisticas de los Fixed Objects recibamos el error 

 sqlplus "/as sysdba"
execute DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
BEGIN DBMS_STATS.GATHER_FIXED_OBJECTS_STATS; END;
*
ERROR at line 1:
ORA-20011: Approximate NDV failed: ORA-00600: internal error code, arguments:
[1350], [3], [23], [60], [AMERICAN], [0], [], [], [], [], [], []
ORA-06512: at "SYS.DBMS_STATS", line 37237
ORA-06512: at line 1

Esto puede darse cuando tenemos la obtencion de estadisticas en auto_sample.
Para solucionarlo, nada mas facil que mover el porcentaje de estimacion a NULL


exec dbms_stats.set_global_prefs(pname=>’ESTIMATE_PERCENT’,pvalue=>’NULL’);


SQL>  select dbms_stats.get_prefs('ESTIMATE_PERCENT') from dual;
DBMS_STATS.GET_PREFS('ESTIMATE_PERCENT')
--------------------------------------------------------------------------------
DBMS_STATS.AUTO_SAMPLE_SIZE

SQL> exec dbms_stats.set_global_prefs(pname=>'ESTIMATE_PERCENT',pvalue=>'NULL');
PL/SQL procedure successfully completed.
SQL> select dbms_stats.get_prefs('estimate_percent') from dual;
DBMS_STATS.GET_PREFS('ESTIMATE_PERCENT')
--------------------------------------------------------------------------------
NULL

Con este sencillo paso podremos ejecutar nuestro paquete de obtencion de estadisticas en los objetos fijos sin eosos errores ORA

kernel.panic_on_oops : Nuevo parametro de la 12c

Posted on por
Responder

Hoy vamos a ver otra de estas pequeñas sorpresas de Oracle en las nuevas versiones
En los requisitos de la instalacion de la version 12c de Oracle nos encontramos con la siguiente nota 

Note: 
The below Kernel Parameter "panic_on_oops=1" is being Introduced and required
 from 12.1.0.2.0 onwards.
kernel.panic_on_oops=1

Que es lo que hace este parametro del Kernel?
Este parametro simplemente controla el comportamiento del kernec cuando un oops or bug es detectado.

Los valores que puede tomar es:

  • 0: INtenta continuar la operacion
  • 1: Entra en panic , ademas de este panica, si el sysctl es distnto de cero, entonces el servidor se reiniciara

Como veis, un parametro bastante inocuo… hasta que buscamos la causa de por que el servidor se ha reiniciado

Nuevas funcionalidades 12c: PGA_AGGREGATE_LIMIT

Posted on por
Responder

Hoy vamos a ver una entrada sencilla sobre una nueva funcionalidad de la 12c , el parámetro PGA_AGGREGATE_LIMIT

Desde la versión 9i Oracle ha apostado por la gestión automática de la memoria, uno de los problemas que generaba Al motor la gestión total de la configuración del tamaño de la PGA y SGA es que el motor podía llegar a configuraciones donde el espacio asignado a la PGA fuese muy alto, repercutiendo sobre la SGA y produciendo un exceso de paginación en la base de datos.

Como han solucionado esto ?

Sencillamente han introducido un parámetro nuevo llamado PGA_AGGREGATE_LIMIT

Este nuevo parámetro va a ser un límite del tamaño total de las PGAs de la base de datos, al contrario de lo que ocurria con PGA_AGGREGATE_TARGET que actuaba como valor de referencia , el nuevo PGA_AGGREGATE_LIMIT actúa como límite , y no solo no dejará que este valor se sobrepase, sino que eliminará sesiones que estén usando mas memoria PGA con el nuevo error ora
ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

¿Cual es el patrón que usa oracle para matar las sesiones

El proceso de background CKPT comprueba cada tres segundos si la cantidad de memoria usada excede el parámetro PGA_AGGREGATE_LIMIT, si este límite es excedido Oracle hará lo sigiuiente

  • Las llamadas de las sesiones que están consumiendo mas PGA son abortadas.(untunable PGA memory)
  • Si el tamaño de la PGA sigue por encima del límite, las sessiones y los procesos que mas PGA usan son terminados (untunable PGA memory)
  • Los procesos de SYS y background no se ven afectados por estas reglas

El motor notifica al cliente el problema con un ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

¿Como se calcula el valor ?

EL PGA_AGGREGATE_LIMIT es un valor dinámico , por lo que puede modificarse en cualquier momento , su valor es calculado de manera automática en el arranque por el motor al mayor de estos tres valores

  • 2 GB
  • 200% of PGA_AGGREGATE_TARGET
  • PROCESSES ( valor del parámetros de incializacion) * 3 MB
  • Nunca excederá al 120% de la memoria física menos el total del tamaño la SGA .

¿Como lo deshabilito?

Si fijamos en el spfile el valor de esta variable a cero, la base de datos se comportará como lo hacía en la version 11g, y no eliminará las sesiones que sobrepasen este límite.
Esto podemos hacerlo con :

alter system set pga_aggregate_limit=0 scope=both;

Mas información en

Rman DUPLICATE en 12c y Windows

Posted on por
Responder

Hoy vamos a ver una sencilla entrada en la que indicaremos como duplicar una base de datos en windows mediante RMAN DUPLICATE.
Este método está muy documentado en un montón de webs, pero , en entornos windows suele tener la pega ( como todo lo de Oracle+Windows) del servicio de windows.

Supongamos que tenemos una base de datos llanada PROD y que queremos clonarla para su uso en desarrollo en otra llamada DESA.
Además de esto, queremos modificar el path de los ficheros de la base de datos, ya que,en la máquina de desarrollo queremos que todo lo que esté en D: y E: pase a estar en Z:

Así pues, los pasos serán:

1- Creamos el init.ora de la instancia a partir de la clonada

Aunque hay documentos que te explican como crear un init mínimo, lo mejor y mas cómodo segun mi opinion es crear un sencillo pfile en texto dsde el spfile del origen

create pfile='initDESA.ora' from spfile;

2- Editamos el initSID.ora y cambiamos TARGET por SID en todas las lineas

Abriremos con cualquier editor el fichero que acabamos de generar y substituiremos la cadena PROD por DESA

3- Creamos el fichero de passwd

Tendremos que ir al $ORACLE_HOME/database crear nuestro fichero de password.

orapwd file=PWDDESA.ora password=mipasswd entries=6 force=y

4- Cramos el servicio de windows

Este es el paso que podemos evitarnos en unix, pero que es inevitable en windows

oradim -NEW -SID DESA -SYSPWD mipasswd -SRVC OracleServiceDESA -STARTMODE auto -SRVCSTART system -SPFILE

5- paramos y arrancamos en modo nomount

El proceso de creacion de servicio habrá arrancado la base de datos , pro lo que tendremos que entrar , pararla y dejarla arrancada en modo nomount.

6- añadimos las líneas de cambio de path en el nuevo INIT.ora

Este es el punto mas extraño ya que, las opciones de cambio de nombre del path del fichero no están en el fichero de comandos de rman, sino en el init.ora de la nueva base de datos.

Con estos comandos movemos tanto los logfiles como los datafiles normales a su nuevo path


LOG_FILE_NAME_CONVERT =('D:\oracle\ORADATA\PROD','Z:\oracle\ORADATA\DESA','E:\oracle\ORADATA\PROD','Z:\oracle\ORADATA\DESA')
DB_FILE_NAME_CONVERT = ('D:\oracle\ORADATA\PROD','Z:\oracle\ORADATA\DESA','E:\oracle\ORADATA\PROD','Z:\oracle\ORADATA\DESA')

7- Creamos el fichero de comandos rman


connect target sys/XXXX.@PROD;
connect catalog user/pass@CATALOG;
connect auxiliary /

CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 4;
CONFIGURE CHANNEL DEVICE TYPE SBT_TAPE parms 'ENV=(NSR_SERVER=backupserver, NSR_DATA_VOLUME_POOL=pollduplicados)';

RUN{
DUPLICATE TARGET DATABASE TO "DESA" ;

}

8-Lanzamos el duplicado

Ahora solamente queda lanzar el rman


rman cmdfile=comandos.crv logfile=duplicacion.log

Y un un tiempo record tendréis duplicada vuestra base de datos PROD renombrada a DESA y en el nuevo path Z:\oracle\ORADATA\DESA