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

Bases de Datos Avanzadas

Para mis alumnos: Todo lo que les enseñaron de Bases de Datos no sirve.

Recreación Manual "dbconsole" 10gR2

Antes de recrear la consola es necesario tener en cuenta que el procedimiento utilizando el emca "Enterprise Manager Configuration Assistant" nos deja la Base de Datos en modo "Quiesce", así que en Bases de Datos en PRODUCCIÓN es recomendable hacerlo cuando se tenga poca carga de trabajo.

El primer paso es entonces, el borrado del repositorio y archivos de configuración:

$ORACLE_HOME/bin/emca -deconfig dbcontrol db -repos drop

Este procedimiento toma algun tiempo en ejecutarse.

Despues de realizar el borrado sigue la creación:

$ORACLE_HOME/bin/emca -config dbcontrol db -repos create

NOTA: Para la versión 10.2.0.4, si se realiza una creación-recreación despues del 31-Dic-2010 es necesario aplicar el parche 8350262. Esto debido a que el certificado usado en el "aseguramiento" de la Consola de Administración expiro en esa fecha.

Como clonar una BD 10g utilizando RMAN

La “clonación” hablando en términos de BD se refiere a la copia idéntica de una BD ya sea en el mismo host u en otro. Por lo general cada cierto tiempo al usuario se le ocurre generar o refrescar su BD de pruebas con información reciente de acuerdo a lo que se tiene en el ambiente de producción, y es cuando nos llega la clásica petición los viernes a las 5:30 pm en la cual nos solicitan una copia de la BD. Para esto se tienen varios métodos; y aquí les comparto uno que es sencillo y rápido….y bueno aquí va el procedimiento:

En el sig ejemplo el host origen tendrá el nombre: MLP y el destino CLON. Y asumimos que ambos se encuentran en modo archive y que en el host destino (CLON) ya existe una BD con el nombre de instancia CLON.

Cabe mencionar que para poder realizar una copia de BD utilizando el método de clonación, es necesario que ambos host tengan el mismo SO y versión de Oracle.

El primer paso es generar un respaldo, utilizando obviamente la herramienta RMAN. Esto se puede hacer de la siguiente forma:

rman target /

crosscheck backupset;

delete noprompt backupset;

run {

allocate channel C1 type disk;

allocate channel C2 type disk;

backup as compressed backupset database format '/backup/%d_%U.dbf';

sql "alter system archive log current";

backup archivelog all format '/backup/%d_%U.arc' delete input;

}

NOTA: Es mandatorio que la estructura de directorio donde generamos el respaldo sea la misma en el host destino (en este caso es /backup/).

Una vez terminado el respaldo se procede a pasarlo al host destino.

Como segundo paso se prepara el ambiente en el host destino para proceder con la clonación:

En caso de que la BD CLON esté ejecutándose se procede a dar de baja la BD y el listener. Una vez la BD y el listener estén abajo se procede a borrar todos los datafiles, redologs, archivelogs y controlfiles; así como también el $ORACLE_HOME/dbs/spfileCLON.ora y se limpian los directorios $ORACLE_BASE/admin/adump, $ORACLE_BASE/admin/bdump, $ORACLE_BASE/admin/cdump, $ORACLE_BASE/admin/udump,,ya que se van a recrear. Se conserva el $ORACLE_HOME/dbs/initCLON.ora y el archivo de passwords $ORACLE_HOME/dbs/orapwCLON.

Posteriormente se procede a editar el archivo $ORACLE_HOME/dbs/initCLON.ora y se agregan los siguientes parámetros:

DB_FILE_NAME_CONVERT=/u00/oradata/, /u01/oradata

LOG_FILE_NAME_CONVERT=/u00/oradata/, /u01/oradata

…en donde en ambos parámetros se indica la ruta origen y destino de los datafiles y logfiles entre los host origen y destino respectivamente (esto en caso de que las estructuras de directorios para dichos archivos, sea distinta en ambos hosts).

Por último es necesario agregar el string de conexión del host origen en el $ORACLE_HOME/network/admin/tnsnames.ora del host destino. Ya que se va requerir para conectarse desde el RMAN a la BD MLP.

Finalmente procedemos a entrar al RMAN desde el host destino (CLON), y ejecutamos el comando para iniciar con la clonación de la siguiente manera:

$ORACLE_HOME/bin/rman target system/pass@MLP auxiliary /

RMAN> duplicate target database to CLON;

Y listo!! Hemos duplicado una BD utilizando la herramiente RMAN.

Uptime en Windows

Existen ocasiones en donde se requiere conocer el tiempo en que el servidor lleva activo (up time), esto para hacer auditorias de seguridad u otra serie de tareas administrativas. En los sistemas unix existe el comando "uptime" que te indica el tiempo (días, horas, minutos y segundos) que el servidor lleva activo, desde la última vez que fue reiniciado.

[oracle@server]:/u00/app/oracle> uptime

4:22pm up 226 days 22:09, 1 user, load average: 0.00, 0.01, 0.03

En Windows no existe ese comando como tal, pero se puede conocer esta información de otra forma. Desde la línea de comandos (command prompt) es necesario ejecutar el siguiente comando:

C:\ >net statistics server

Server Statistics for \\WinServer

Statistics since 2/26/2009 8:40 AM

…

…

The command completed successfully.

Así se puede conocer la fecha exacta desde cuándo se están tomando las estadísticas del servidor, es decir, la última vez que fue reiniciado.

Perdida del archivo targets.xml en el Agente del Grid Control

Si por error (generalmente y pensemos que fue de dedo y por supuesto no tenemos respaldo del archivo) se perdió (borro, elimino, suprimió, aniquilo, inutilizo, etc.) el archivo targets.xml
que se encuentra en $ORACLE_HOME/sysman/emd
($ORACLE_HOME es el "Home" del Agente del Grid Control) con el siguiente procedimiento podremos volver a recrearlo.

- Crear (recrear) el archivo targets.xml

• En Windows crear un archivo de de texto en el directorio indicado en el "Home" del Agente %ORACLE_HOME%/sysman/emd
  
• En Unix ir al directorio indicado en el "Home" del Agente
  

cd $ORACLE_HOME/sysman/emd

touch targets.xml

- Una vez que el archivo ya esta creado obtenemos los valores siguientes

agentSeed y EMD_URL

ejemplo:

…

agentSeed=162758739

…

EMD_URL=https://oemgc.trix.com:3872/emd/main/

…

Estos los encontramos en el archivo emd.properties que se encuentra en el siguiente directorio en el "Home" del Agente $ORACLE_HOME/sysman/config

- En el archivo targets.xml creado anteriormente agregamos el siguiente bloque en el archivo (ojo en el mismo formato que se muestra)

<Targets AGENT_SEED="162758739">

<Target TYPE="oracle_emd" NAME=" oemgc.trix.com:3872"/>

<Target TYPE="host" NAME=" oemgc.trix.com"/>

</Targets>

- Salvamos el archivo y a continuación ejecutamos el comando agentca
con la opción "-d"

agentca -d

NOTA:

Antes de realizar este procedimiento debes dejar sin información el directorio $ORACLE_HOME/sysman/emd en el "Home" del Agente

rm -rf agntstmp.txt lastupld.xml recv/* collection/* upload/* state/*

Los directorios que están dentro los debes preservar.

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

Como saber la versión de Oracle Application Server que está instalada

El día de ayer tuve un pequeño problema para determinar la versión exacta del Servidor de Aplicaciones que estaba instalado, lo cual es necesario para instalar parches y llevar a cabo tareas de mantención. Como el Servidor de aplicaciones de Oracle instala tantos componentes, y cada uno tiene su propia versión, puede ser un poco complicado saber la versión del OAS instalado, a menos que sepas el archivo exacto donde está almacenado este dato. Buscando en Metalink encontré la solución:

Abrir el archivo $ORACLE_HOME\config\ias.properties. En este archivo se debe de buscar la sección de [InstallData] y en el atributo de "Version" se encuentra el dato que estas buscando:
Version=10.1.2.0.0

Espero que esto les sea de utilidad, ya que luego es un dolor de cabeza saber cual es la versión exacta de cada producto cuando se tienen tantos servidores en mente

Saludos.
CAFÚ

ORACLE_HOME

Que les parece....

Funciona tanto en 9i como en 10g

SELECT substr(file_spec,1,instr(file_spec,'lib')-2) ORACLE_HOME
FROM dba_libraries
WHERE library_name='DBMS_SUMADV_LIB';

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

Iniciamos a petición de CAFU...

Bien, pues despues de tanto insistir, vamos a iniciar este blog, el nombre se lo debemos al buen Robert.
Poco a poco lo vamos a ir mejorando... no me presionen