chistorete DBA (m4m0n)

Pregunta desarrollador: ¿Que otros esquemas están además del mío?
Respuesta DBA (m4m0n):   select unique OWNER from all_objects order by 1
Respuesta desarrollador: Ya entiendo
Respuesta DBA (m4m0n en la mente): No lo creo jajajaja

Proceso OCSSD.BIN

Si tienes instalado una base de datos Oracle 10g en algún “Oracle Home” y detectas que tienes un proceso llamado ocssd.bin :

ps -ef | grep css
oracle 651 1 0 16:41 ? 00:00:00 /u01/app/oracle/product/10.2.0/db/bin/ocssd.bin

Esto es completamente normal, este proceso es usado por las instalaciones de tipo RAC y ASM. En una instalación no-RAC este proceso es utilizado para la comunicación entre la instancia de la base de datos y la instancia de ASM (Automatic Storage Management). Aunque no se estén usando estos componentes, el proceso aún se encuentra corriendo y es colocado en el “inittab” para que se inicialice cada vez que la máquina se reinicialice, cabe mencionar que este proceso corre con privilegios de root.

Este proceso no es esencial para el correcto funcionamiento de la base de datos (si es que no se tienen instalados los componentes de RAC y ASM), es por eso que se recomiendo quitarlo para evitar futuros incidentes relacionados con él.

El prodimiento para detener y remover este proceso del “inittab” es el siguiente:
Con la cuenta de “root” ejecutar el siguiente comando:

  root@localhost root]# ps -ef|grep css
oracle     651     1  0 16:41 ?        00:00:00 /u01/app/oracle/product/10.2.0/db/bin/ocssd.bin
root      2353 31469  0 17:01 pts/1    00:00:00 grep css
[root@localhost root]# /etc/init.d/init.cssd stop
Stopping Cluster Synchronization Services.
Shutting down the Cluster Synchronization Services daemon.
Shutdown request successfully issued.
Shutdown has begun. The daemons should exit soon. 

Una vez hecho esto, procederemos a removerlo del inittab. En el archivo /etc/inittab se tiene que comentar la siguiente linea (esto también lo tiene que hacer root):

#h1:35:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 </dev/null

Cabe hacer notar que es indispensable detener el proceso OCSSD.BIN antes de querer instalar cualquier “Patchset” para la base de datos, de lo contrario te marcará el siguiente error:

Oracle Universal Installer has detected that there are processes running in the currently selected Oracle Home.
The following processes need to be shutdown before continuing:
/u01/app/oracle/product/10.2.0/db/bin/ocssd.bin
Help   Retry   Cancel 

/etc/hosts en ORACLE

En los Sistemas tipo Unix el archivo /etc/hosts (en windows su equivalente es: C:\Windows\System32\Drivers\etc\hosts) almacena una la lista de direcciones IP y los nombres que corresponden a la máquina en la que éste archivo se encuentra. Regularmente sólo contiene entradas, que corresponden a la máquina local y a las máquinas más “importantes” (como el gateway, servidor DHCP, etc.) de la red a la que pertenece.

Un ejemplo de este archivo puede ser:

127.0.0.1 localhost
10.25.0.114 prod23db prod23db.company.com.mx

Antes de instalar cualquier producto de ORACLE, cerciórate de que este archivo se encuentre en el siguiente formato:

IP full_qualified_hostname hostname

Ejemplo:

127.0.0.1 localhost
10.25.0.114 prod23db.company.com.mx prod23db

¿Por qué hay que fijarse en esto antes de instalar? Porque algunos servicios de los productos de ORACLE hacen uso de la información contenida en este archivo, y toman como referencia el primer nombre del host que se especifica en este archivo. Si el “hostname” no es el correcto, estos servicios no funcionarán correctamente. En el ejemplo anterior, supongamos que la configuración de algún producto de Oracle, tome como nombre de la máquina “prod23db” y no “prod23db.company.com.mx”, las máquinas que se encuentran fuera de la subred donde está este servidor no van a poder visualizar los servicios. En el caso remoto de que los puedan visualizar, les van a marcar varios errores.

En el caso de la Base de Datos (10g en adelante), la consola de administración (dbconsole) toma los datos de este archivo para realizar la configuración. Si no se hace este cambio en el archivo antes de la instalación, es posible recrear el repositorio de la consola una vez que se haya modificado el archivo /etc/hosts correctamente:

$ emca -config dbcontrol db -repos create

En el Caso del Oracle Application Server (10g R1 en adelante), también toma los datos del /etc/host para configurar varios servicios y productos. Si se tiene alguna de los siguientes tipos de instalación:

• Middle-tier
  
• Infrastructure: Identity Management only
  
• OracleAS Certificate Authority
  

Es posible hacer el cambio del hostname siguiendo los pasos descritos en este sitio. Pero si se tiene alguna de las siguientes instalaciones:

• Infrastructure: Identity Management and Metadata Repository
  
• Infrastructure: Metadata Repository only

Te puedo decir: “Laaaastima MARGARITOOO” porque no es posible hacer el cambio del hostname. Lo que significa que vas a tener que reinstalar todos los componentes antes descritos.

Es por eso que te recomiendo AMPLIAMENTE que te fijes en el /etc/hosts antes de instalar cualquier producto de ORACLE y te evites dolores de cabeza.

CAFU

Cambiando las Contraseñas de SYSMAN y DBSNMP

Existe un sin número de razones por las cuales se puede requerir cambiar las contraseñas de las cuentas utilizadas para administrar la base de datos. Uno de los motivos más importantes es la seguridad.

Con respecto a las cuentas de ‘sys’ y ‘system’ no hay mucho problema para cambiar las contraseñas. Lo único que se requiere hacer es :

ALTER USER SYS IDENTIFIED BY <new_password>;
ALTER USER SYSTEM IDENTIFIED BY <new_password>;

Pero para las cuentas de sysman y dbsnmp es una historia completamente distinta. Si por error cambiaste las contraseñas de estas cuentas con el procedimiento descrito anteriormente, te puedo asegurar que muy probablemente ahora te estás arrepintiendo de haber hecho eso y estás maldiciendo a los dioses de las bases de datos por no haber impedido que lo hicieras (lo puedo decir por experiencia propia).

Pero bueno, todo tiene una solución. A continuación mostraré los pasos que se requieren seguir para cambiar las contraseñas de estas dos cuentas:

Cuenta SYSMAN:

1.- Asegúrate de que la variable de ambiente ORACLE_HOME esté definida correctamente.
2.- Detén la consola de administración de la BD: dbconsole
En Unix:
>$ORACLE_HOME/bin/emctl stop dbconsole
En Windows:
C:\>%ORACLE_HOME%\bin\emctl stop dbconsole
O en su defecto puedes detener el servicio llamado: Oracle<oracle_home_name>DBConsole

3.- Asegúrate de que la consola “dbconsole” este detenida.

En Unix:
>$ORACLE_HOME/bin/emctl status dbconsole
En Windows:
C:\>%ORACLE_HOME%\bin\emctl status dbconsole
O en su defecto puedes verificar el status del servicio llamado: Oracle<oracle_home_name>DBConsole

4.- Conéctate a la base de datos por medio del SQL*Plus con un usuario que tenga privilegios de DBA y ejecuta lo siguiente:

SQL> ALTER USER SYSMAN IDENTIFIED BY <new_password> ;

5.- Verifica que la nueva contraseña sea correcta

SQL> CONNECT SYSMAN/<new_password>[@database_alias]

6.- Dirígete al siguiente directorio: $ORACLE_HOME/[HOST]_[SID]/sysman/config

• Dentro del directorio guarda un respaldo del archivo emoms.properties, nombrándole emoms.properties.old
• Edita el archivo emoms.properties
• Busca la línea que empieza con: oracle.sysman.eml.mntr.emdRepPwd=
  Remplaza el valor encriptado, asignándole como valor la nueva contraseña.


• Busca la línea: oracle.sysman.eml.mntr.emdRepPwdEncrypted=TRUE
  
  Remplaza el valor de TRUE por FALSE

7.- Reinicia la consola de administración: dbconsole
En Unix:
>$ORACLE_HOME/bin/emctl start dbconsole
En Windows:
C:\>%ORACLE_HOME%\bin\emctl start dbconsole
O en su defecto puedes iniciar el servicio llamado: Oracle<ORACLE_HOME_NAME>DBConsole
8.- Asegúrate de que la contraseña se haya encriptado.

• Edita el archivo emoms.properties
• Busca la línea que empieza con: oracle.sysman.eml.mntr.emdRepPwd=
  Verifica que el valor de la contraseña esté encriptado.
• Busca la línea: oracle.sysman.eml.mntr.emdRepPwdEncrypted=TRUE
  Asegúrate de que el valor esté en TRUE

Cuenta DBSNMP:
1.- Asegúrate de que la variable de ambiente ORACLE_HOME esté definida correctamente.
2.- Detén la consola de administración de la BD: dbconsole
En Unix:
>$ORACLE_HOME/bin/emctl stop dbconsole
En Windows:
C:\>%ORACLE_HOME%\bin\emctl stop dbconsole
O en su defecto puedes detener el servicio llamado: Oracle<oracle_home_name>DBConsole

3.- Asegúrate de que la consola “dbconsole” este detenida.
En Unix:
>$ORACLE_HOME/bin/emctl status dbconsole
En Windows:
C:\>%ORACLE_HOME%\bin\emctl status dbconsole
O en su defecto puedes verificar el status del servicio llamado: Oracle<oracle_home_name>DBConsole

4.- Conéctate a la base de datos por medio del SQL*Plus con un usuario que tenga privilegios de DBA y ejecuta lo siguiente:
SQL> ALTER USER DBSNMP IDENTIFIED BY <new_password> ;

5.- Verifica que la nueva contraseña sea correcta

SQL> CONNECT DBSNMP /<new_password>[@database_alias]

6.- Dirígete al siguiente directorio: $ORACLE_HOME /[HOST]_[SID]/sysman/emd

• Dentro del directorio guarda un respaldo del archivo targets.xml, nombrándole targets.xml.old
• Edita el archivo targets.xml
• Busca la línea: <Property NAME=”password” VALUE=”<[valro de la contraseña encriptado]>” ENCRYPTED=”TRUE”/>
  Remplaza el valor encriptado, asignándole como valor la nueva contraseña. También remplaza el valor de TRUE por FALSE
  

7.- Reinicia la consola de administración: dbconsole
En Unix:
>$ORACLE_HOME/bin/emctl start dbconsole
En Windows:
C:\>%ORACLE_HOME%\bin\emctl start dbconsole
O en su defecto puedes iniciar el servicio llamado: Oracle<ORACLE_HOME_NAME>DBConsole
8.- Asegúrate de que la contraseña se haya encriptado.

• Edita el archivo targets.xml
• Busca la línea: <Property NAME=”password” VALUE=”<[valor de la contraseña encriptado]>” ENCRYPTED=”TRUE”/>
  Verifica que el valor de la contraseña esté encriptado y que el valor esté en TRUE

CREO QUE ESTA FALLANDO LA BASE DE DATOS

Pues va el primero… por supuesto estamos hablando de un Base de Datos ORACLE.

Que debemos revisar cuando nos llaman y dicen, “creo que tenemos problemas con la Base de Datos porque la aplicación no responde” Después de eso empiezas a pensar “¿mmm será?” Y dado que no sabemos qué pasa y la persona que nos habla NO TIENE IDEA de que sucede, obviamente debemos revisar la “Base de Datos”

Primer punto…

“alert log”, ¿en donde lo encontramos? Generalmente estará en el directorio admin/SID/bdump. En este archivo encontramos la información cronológica de mensajes y errores, asi como ciertas tareas administrativas. El “alert log --> alter_SID.log” es uno de los que podemos obtener información valiosa de que está pasando con nuestra Base de Datos.

“listener log”, ¿en donde lo encontramos? Generalmente estará en el directorio $ORACLE_HOME/network/log. En este archivo podemos ver información de conexiones a la base de datos a través del listener.

Segundo punto…

Claro esta, entrar con el sqlplus a la Base de Datos, antes que nada si se tiene la opción de entrar con un “usuario mortal” hacerlo y ejecutar un simple query como

SELECT 1
FROM DUAL;

Otros serian checar como sysdba

SELECT *
FROM v$instance;

SELECT *
FROM v$resource_limit;

Ahora bien si ya sabes que es lo que generalmente pasa cuando “tenemos problemas con la base de datos” es recomendable tener una serie de queries y/o scripts que nos regresen la información necesaria para saber que está pasando. En mi caso para las bases de datos que tengo a mi cargo algunas consultas muy simples pero que me dan de entrada mucha información de que está pasando.

SELECT status, TYPE, machine, COUNT (*)
FROM v$session
WHERE username = '&USUARIO_CON_PROBLEMAS'
GROUP BY status, TYPE, machine;

SELECT machine, COUNT (*)
FROM v$session
GROUP BY machine;

SELECT username, machine, COUNT (*)
FROM v$session
GROUP BY username, machine;

Tercer punto…

¿Tenemos jobs ejecutándose que estén fallando? ¿Tenemos entradas en el cron ejecutándose que estén fallando? ¿tenemos lleno algún filesystem y/o disco?

Con estos puntos, podemos empezar a analizar el “creo que tenemos problemas con la base de datos porque la aplicación no responde”.