Una manera sencilla y muy efectiva de mirar los parámetros definidos en una base de datos Oracle es desde SQLPLUS:
Conectados como SYS o SYSTEM podemos hacer:
$ sqlplus /nolog
SQL> connect /as sysdba;
SQL> show parameter <nombre parámetro>
Ejemplo:
SQL> show parameter processes
Otra manera …
SQL> select value from v$parameter where name=’processes’;
Para versiones 11G podemos ejecutar sólo:
SQL> show parameter
Nos mostrará todos los parámetros y su valor definido en ese momento.
Es bien sencillo:
Desde sqlplus conectado con el usuario propietario de la tabla o con system …
CREATE TABLE <USUARIO.NOMBRE_TABLA_NUEVA> AS SELECT * FROM <TABLA_EXISTENTE>;
Ejemplo:
CREATE TABLE OPS$PEPITO.TABLA_PEPITO_18122012 AS SELECT * FROM PEPITO.TABLA_PEPITO;
En muchas ocasiones nos encontraremos que en la documentación de Oracle se ha de ejecutar alguna instrucción usando el comando “sudo” de Linux. Pero puede suceder que no tengamos configurada la posibilidad del uso de ese comando para el usuario oracle o el usuario que vayamos a utilizar para la instalación y nos sale un error como este:
$ sudo root
oracle is not in the sudoers file. This incident will be reported.
Seguidamente os explico como podemos configurar el comando sudo para poderlo usar en Redhat de la misma manera como se usa en Ubuntu o Debian.
Tenemos que hacerlo conectados como “root”. O bien, pedirle al administrador que tenga la cuenta de root que haga lo siguiente:
editar el archivo /etc/sudoers.
$ su -
# vi /etc/sudoers
al final del archivo pondremos la siguiente línea (se debe poner el nombre de usuario que queremos que pueda usar el comando “sudo”, en este ejemplo “oracle”):
oracle ALL=(ALL) ALL
Con ésto ya podremos usar el comando sudo con nuestra cuenta de usuario “oracle” en este caso. Siempre y cuando en la variable de entorno del PATH del usuario Oracle tengamos definida la ruta donde se encuentra el comando “sudo” y el comando lo podamos ejecutar con el usuario en concreto (es decir, tenga permisos de ejecución para ese usuario).
OPatch
Es una herramienta que usa Oracle para instalar sus propios parches. Se puede descargar de Oracle Support (antiguo metalink) buscando normalmente el Patch 6880880.
Pasos…
$ cd $ORACLE_HOME
Renombrar el antiguo OPatch instalado….
$ mv OPatch OPatchOLD
Copiar el fichero descargado comprimido de OPatch bajado de Internet al directorio $ORACLE_HOME.
Procurar tener la última versión de OPatch, que puedes obtener buscando el Patch 6880880 en Oracle Support (Antiguo metalink).
$ ls –l p6880880_112000_Linux-x86-64.zip
$ unzip p6880880_112000_Linux-x86-64.zip
$ opatch -help (en la cabecera sale la versión actualizada)
Tiene que salir el directorio OPatch ya creado y el OPatchOLD que renombramos anteriormente. Pues ya estaría instalado. Ahora para que funcione deberíamos configurar la variable de entorno para que se ejecute desde cualquier ruta.
Ya podríamos eliminar el fichero .zip del directorio OPatch creado.
Configurar la variable de entorno PATH del usuario Oracle:
Este paso se puede hacer antes o después de la instalación. Si se ha usado alguna vez OPatch, seguramente esta variable de entorno ya estará configurada.
Añadir :$ORACLE_HOME/OPatch a la variable de entorno PATH
Entrar como el usuario “oracle” al servidor:
$ vi ~/.bash_profile
Anadir la siguiente linea (texto en negrita) a la variable de entorno PATH….
PATH=$PATH:$ORACLE_HOME/bin:$ORACLE_HOME/OPatch
export PATH
Salir y volver a entrar con el usuario oracle para que se cargue la variable de entorno.
Los pasos para cambiar el character set de una base de datos Oracle hasta la versión 8i se hace de la siguiente manera:
Desde la consola de SQLPLUS:
1) shutdown immediate;
2) startup mount;
3) alter system enable restricted session;
4) alter system set job_queue_processes=0;
5) alter database open;
6) alter database character set WE8ISO8859P1; (en esta línea, va el juego de caracteres al que queremos pasar nuestra BD)
7) shutdown immediate;
startup;
¡Y con eso es todo!
Hay que tener en cuenta que si la BD ya tiene información almacenada pueden salir registros con carácteres “extraños” que se tendrían que modificar y puede ser bastante engorroso. Yo recomiendo estos pasos para BD que se pueden modificar esos carácteres extraños de manera fácil, o BD que no tienen información y que hemos creado con un CHARACTER SET erróneo.
Para VER que CHARACTER SET tenemos instalado podemos ejecutar:
SQL> select * from nls_database_parameters;
Para versiones posteriores crearé otro post con todos los pasos necesarios.
Es importante saber cómo mirar los valores del Kernel en Linux definidos para Oracle. Esto nos puede ser útil para cuando vamos a realizar una instalación del servidor de Base de datos, o bien cuando queremos modificar algún parámetro ya definido anteriormente.
Consultar sobretodo la documentación de Oracle para cualquier nueva instalación.
Aquí se explica como consultar los valores una vez definidos, cómo modificarlos y como reiniciar el kernel sin tener que rebotar el S.O.
# env | grep ORACLE
ORACLE_SID=XE
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe
# sysctl -p |grep kernel
kernel.sysrq = 0
kernel.core_uses_pid = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
# sysctl -a |grep kernel | grep shm
kernel.shmmax = 429496729
kernel.shmall = 2097152
kernel.shmmni = 4096
kernel.shm_rmid_forced = 0
# sysctl -a | grep kernel | grep sem
kernel.sem = 250 32000 100 128
# df -k /dev/shm <— Esto es la RAM
Filesystem 1K-blocks Used Available Use% Mounted on
none 2877236 200 2877036 1% /run/shm
Para modificar y añadir cualquier valor al kernel en Linux tenemos el fichero “/etc/sysctl.conf”. Una vez añadidos los valores que desamos podemos hacer ….
Ejecutar la siguiente instrucción para cambiar y actualizar los parámetros del kernel actuales sin tener que rebotar el S.O:
/sbin/sysctl -p
Para comprobar que los cambios se han guardado ejecutar:
/sbin/sysctl -a
Nota: Lo mejor es sin duda, reiniciar el servidor: (# shutdwon -r 0)
Hay que tener en cuenta que la SGA es mucho más de lo que hay explicado aquí, pero esto es una guía para solucionar problemas que pueden aparecer y entenderla de manera mas rápida
Definición:
SGA (Área Global del Sistema) es una estructura básica de memoria de Oracle que sirve para facilitar la transferencia de información entre usuarios y también almacena la información estructural de la BD más frecuentemente requerida.
El área global del sistema y un conjunto de procesos de la base de datos constituyen una instancia de una base de datos Oracle. La base de datos Oracle automáticamente reserva memoria para el área global del sistema cuando se inicia una instancia, y el sistema operativo reclama la memoria cuando se apaga dicha instancia. Cada instancia tiene su propia SGA.
¿Que contiene la SGA?
Memoria Oracle (SGA) Su tamaño está determinado por los parámetros:
• Shared_Pool_Size= Tamaño en bytes del área para SQL compartidos y sentencias PL/SQL.
• Db_Block_Size = Tamaño en bytes de un solo bloque de datos.
• Db_Block_Buffers = Numero de Buffers a localizar en memoria.
• Log_Buffer = Numero de bytes localizados para los Redo Log Buffer.
Está Compuesto por:
• Los Redo Log Buffers
• Los Database Buffers
• Shared SQL Pool
Oracle descarga / libera la información contenida en la shared pool por cualquiera de las siguientes razones:
• Si un objeto del esquema referenciado en una sentencia sql, es modificado posteriormente en cualquier manera, el área del sql compartido es invalidado y la sentencia tendrá que ser recompilada la próxima vez que se ejecute.
• Si se cambia el nombre global de la base de datos, toda la información en en la shared pool es descargada.
• El administrador puede manualmente desalojar toda la información en esta área compartida para evaluar el rendimiento con respecto a ésta área de memoria, que sería esperada luego de que la instancia inicie sin apagar la instancia actual. La sentencia ALTER SYSTEM FLUSH SHARED_POOL es usada para esto (versiones 10 o posterior).
El total disponible de memoria en un sistema tiene que estar configurado de forma que todos los componentes de ese sistema funcionen óptimamente. Una pauta a seguir para que el sistema quede bien configurado podría ser el siguiente:
¿ Que tamaño dar a la SGA en un sistema nuevo o del que conocemos el número de usuarios, procesos, etc…?
Oracle SGA Componentes –> 50% del total de la memória del sistema
Sistema operativo + Otros –> + o – 15% del total de la memória del sistema
Memoria de usuario –> + o – 35% del total de la memória del sistema
Esta es la primera pauta que podemos seguir a la hora de reservar o ver la memoria que se necesita o que se puede poner cómo máximo en un sistema para que Oracle funcione correctamente y los demás componentes del sistema puedan hacerlo también. ( habría que tener en cuenta también el número de usuarios que accederán concurrentemente al sistema).
Una vez que hemos decidido que la SGA de nuestra base de datos ORACLE va a ser el 50% de la memoria total del sistema. Esta memoria la tenemos que dividir entre los componentes que la forman. (Database buffer cache, shared_pool_area, fixed size, redo log buffer).
Componentes de la SGA (Memoria SGA)
Database Buffer Cache ~80% de la SGA
Shared Pool Area ~12% de la SGA
Fixed Size ~1% de la SGA
Redo Log Buffer ~0.1% de la SGA
Seguidamente se muestran una serie de consultas básicas que nos darán la información que necesitamos para saber como está la SGA.
• La siguiente consulta nos da información de la Shared Pool indicando el espacio ocupado/libre tanto en bytes como en megabytes.
select * from ( select POOL, NAME, BYTES, BYTES/1048576 as MBytes from v$sgastat where pool=’shared pool’ order by BYTES desc ) where rownum <= 25;
El campo “free memory” es el que indica el espacio libre en esos momentos. Para sacar exactamente TOTALES de espacio de la SGA ocupado y libre, ejecutaremos la siguiente sentencia:
select name,to_number(value/1024/1024) Mbytes
from v$parameter where name =’shared_pool_size’
union all
select name,bytes/1024/1024
from v$sgastat where pool = ‘shared pool’ and name = ‘free memory’;
Esto nos devolverá en MB el espacio total ocupado y libre de la SGA. Podemos comprobar que nos devuelve el resultado correcto mirando directamente en los parámetros generales de Oracle de la siguiente manera:
select * from v$system_parameter
where name like ‘%shared%’;
Nos dará el valor en bytes una descripción de los parámetros de Oracle.
Un error típico que suele dar relacionado con la SGA es el ORA-04031
Este error es fácil de solucionar siempre y cuando se tenga claro que es debido a que falta espacio en la SGA, bien porque se ha quedado pequeña, se definió mal desde un principio o porque está muy fragmentada.
Existe un comando que libera la SGA sin tener que parar la BBDD a partir de la versión 10 de Oracle. Este comando es el siguiente:
SVRMGRL> alter system flush shared_pool;
Ejemplo:
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.4.0 – Production
JServer Release 8.1.7.4.0 – Production
SQL> select count(*) from v$sqlarea;
COUNT(*)
———-
828
SQL> alter system flush shared_pool;
System altered.
SQL> select count(*) from v$sqlarea;
COUNT(*)
———-
18
También desde la version 10 de Oracle podemos modificar el tamaño en caliente. Se haría de la siguiente manera:
SVRMGRL> alter system set shared_pool_size = 400M;
SVRMGRL> alter system set shared_pool_reserved_size = <15% de la shared_pool_size>;
Se ha de tener en cuenta que a partir de las versión 10 de Oracle si se tiene el parámetro SGA_TARGET activado, será Oracle quien automáticamente gestione la memória de la SGA. Por tanto, la modificación de los parámetros shared_pool_XXXX no tendrán efecto.
Manipulación de los parámetros del SGA
Existen tres tipos de parámetros en oracle:
- Parámetros “fijos”=> Son parámetros que una vez instalada la base de datos no se pueden volver a modificar / configurar. El juego de caracteres es un claro ejemplo.
- Parámetros Estáticos => Son parámetros que se pueden modificar, pero su modificación implica cerrar la base de datos y volverla a abrir para que los lea del fichero y pueda realizar el cambio.
- Parámetros Dinámicos=> Son parámetros cuyo valor se puede cambiar sin necesidad de cerrar la base de datos a diferencia de los estáticos.
Podemos asignar valores a los parámetros de la siguiente manera:
SQL> ALTER SYSTEM SET <parámetro> = <valor> [SCOPE = <ámbito>]
El valor del ámbito puede ser uno de los siguientes.
• spfile –> Fichero de parámetros
• memory –> En memória (en caliente)
• both –> En memória y en el fichero de parámetros spfile.
Ejemplo:
El ejemplo anterior sólo funciona a partir de la versión 9.
Para ver el valor actual de un parámetro.
SQL> show parameter <parámetro>
Existe una manera sencilla de verificar que parámetros son dinámicos y cuales son estáticos.
La vista V$PARAMETER nos proporciona este tipo de información.
La columna ISSYS_MODIFIABLE contiene tres (3) tipos de valores:
• Immediate
• Deferred
• False
Por ejemplo:
SQL> select distinct ISSYS_MODIFIABLE from V$PARAMETER;
ISSYS_MODIFIABLE
—————————
IMMEDIATE
DEFERRED
FALSE
IMMEDIATE: identifica aquellos parámetros dinámicos, es decir, los ajustes se realizan de manera inmediata.
DEFERRED: los ajustes pueden ser realizados en “caliente” pero tomarán efecto solo después de que la base de datos sea re-inicializada.
FALSE: obligatoriamente la base de datos debe bajarse para poder efectuar el cambio.
La siguiente sentencia nos permite conocer lo anterior mencionado:
Col NAME format a50
Col ISSYS_MODIFIABLE format a20
Select NAME, ISSYS_MODIFIABLE
From V$PARAMETER
Order by 1
Para mostrar el estado actual del SGA.
SQL> show sga
Bienvenido al BLOG de Administración de Oracle de Francisco García Colacios. Este blog nace con un objetivo primordial: conseguir que lo que se explica en el mismo ”facilite la vida” a los lectores cuando se enfrenten con un problema relacionado con las Bases de datos Oracle, de manera que encuentren una solucion efectiva y rápida para que puedan invertir el tiempo en hacer otras cosas más importantes y divertidas que administrar una base de datos.
