A partir de la de versión 8i, no es necesario registrar los servicios de BD en el fichero listener.ora, las BD se pueden registrar automáticamente.
Esta funcionalidad funciona perfectamete si tenemos el listener en el puerto 1521 (por defecto), si realizamos un cambio de puerto no hay forma de conectarnos a la BD. Esto ocurre porque el valor de la parámetro LOCAL_LISTENER que por defecto es:
En algunos casos es interesante realizar la instalación completa en modo texto. Alguna vez me he encontrado con la imposibilidad de trabajar con ratón (parece moverse con vida propia) durante la configuración de una máquina en un Blade (no se si será por el navegador, la configuración del Blade o…).
El caso es que en esas situaciones es mejor realizar la instalación en modo texto y listo. Esto se puede forzar en la primera pantalla de bienvenida durante la instalación, si nos ponemos encima de «Install or upgrade an existing system» y pulsamos tab aparece:
vmlinuz initrd=initrd.img
Pues si añadimos text al final:
vmlinuz initrd=initrd.img text
Y pulsamos return ya lo tenemos.
Cada vez de forma más frecuente, podemos vernos en la necesidad de instalar un SO (Red Hat o Fedora) sobre un servidor físico sin unidad de DVD.
En estos casos a partir de la ISO del DVD podemos preparar un pendrive USB para realizar la instalación por red. Los pasos son:
Ya tenemos el pendrive listo para arrancar, curiosamente en el DVD de Centos no contiene esta imagen.
Un excelente ejercicio para verificar que los backups se realizan correctemente, es preparar un script que nos haga una restauración a demanda en otro servidor (normalmente preproducción).
Digo una restauración y no un clonado (que es algo realmente impresionante el poder clonar una BD sin pararla hasta el momento actual), porque el clonado necesita que la BD de origen (producción seguramente) tiene que estar abierta y en caso de desastre esto no lo vamos a terner claro.
La restauración que se muestra aquí se realiza sin catálogo RMAN externo (es decir usando el controlfile como catálogo), esto nos obliga tener activa la opción:
Este error es producido por un bug reconocido por Oracle que se puede encontrar en el Metalink fácilmente [ID 4483084.8], el error indica que se ha intentado parar la BD sin que el Library Cache estuviese vacío.
La solución propuesta de forma oficial es migrar a 11.1.0.6 y además indica que no produce ningún tipo de corrupción en los datafiles, sugiriendo que nos podemos acostumbrar a verlo en el alert sin preocuparnos.
Lo que no dicen es que este error puede hacer que una parada de BD con un típico shutdown immediate, puede fallar y quedarse la BD en estado nomount, esto me ha pasado en sistemas HP-UX. Si ocurre durante una copia fría de fin de semana, la BD no arrancará porque ya lo está, pero claro en nomunt.
En la versión de Oracle 11g se pueden pasar parámetros desde linea de comandos a RMAN, en las versiones anteriores esto no es posible.
Lo que he hecho en estos casos es desde un scripts bash:
Un pequeño script para arrancar automáticamente una BD Oracle:
# chkconfig: 2345 80 20
# description: Oracle Database
#!/bin/bash
start() {
su - oracle <<EOF
lsnrctl start
sqlplus / as sysdba<<EOO
startup
EOO
EOF
}
stop() {
su - oracle <<EOF
sqlplus / as sysdba<<EOO
shutdown immediate
EOO
lsnrctl stop
EOF
}
case "$1" in
start)
start
;;
stop)
stop
;;
*)
echo $"Usage: $0 {start|stop}"
esacArranca la BD como usuario «oracle», que tiene que tener todas las variables de entorno correctemente configuradas (especialmente ORACLE_SID).
Este script se puede instalar con chkconfig ya que tiene la cabecera preparada para ello.
No es la primera vez que me veo en la necesidad de ejecutar un DML que actualiza relamente muchos rows, esto puede ser un problema porque el tablespace UNDO no es infinito (ni debe serlo).
Recientemente he tenido que ejecutar un update: