Juan Andres Mercado Oracle Blog
Troubleshooting daily on Oracle Systems, Linux & more !
Hoy vamos a trabajar un poco con las instancias de ASM y la manera en que podemos desenvolvernos con la linea de comandos.
Vamos a comenzar cargando las variables de ambiente.
$ cat asm.sh export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_asm export ORACLE_SID=+ASM export PATH=$PATH:$ORACLE_HOME/bin export EDITOR=vi $. ./asm.sh
Comenzamos por loguearnos a la terminal de administracion de ASM usamos el comando asmcmd.
$ asmcmd ASMCMD>
Para realizar una optima instalación de un motor de base de datos, u OAS es importante chequear bien lo prerequisitos de la documetación oficial.
Red Hat Enterprise Linux 4.0: binutils-2.15.92.0.2-10.EL4 compat-db-4.1.25-9 control-center-2.8.0-12 gcc-3.4.3-9.EL4 gcc-c++-3.4.3-9.EL4 glibc-2.3.4-2 glibc-common-2.3.4-2 gnome-libs-1.4.1.2.90-44.1 libstdc++-3.4.3-9.EL4 libstdc++-devel-3.4.3-9.EL4 make-3.80-5 pdksh-5.2.14-30 sysstat-5.0.5-1 xscreensaver-4.18-5.rhel4.2
Algunas veces ocurre que trabajamos con servidores bajo plataformas de 32bits (i386) o 64bits (x86_64) y esto es imortante tenerlo en cuenta a la hora de la instalación de los paquetes necesarios.
Ahora bien, cuando tenemos instalado un sistema operativo de 64 bits en un servidor de 64 bits, si queremos correr binarios o aplicaciones construidas bajo 32 bits, va a precisar que estas esten instaladas estas librerias.
Ejemplo para una aplicación de Python que corre en 64bits.
|Bin | Lib | ArCh | |sqlplus | setuptools-0.6c11 | x86_64 | |sqlplus | setuptools-0.6c11 | i386 |
En el caso puntual que voy a exponer como problema, transcurre en un Red Hat 4, y para ver un mejor detalle de la version del SO, voy a ejecutar un cat sobre el archivo /etc/issue
[root@sdat4104lx ~]# cat /etc/issue Red Hat Enterprise Linux ES release 4 (Nahant Update 8) Kernel \r on an \m
Cuando agregamos diskgroups en el ASM, debemos revisar que se haya registrado correctamente en el spfile de ASM,
ya que este archivo es leido por la instancia al inicio y monta todos los discos que se encuentran alli especificados.
Es asi, que al levantar las instancias de BAse de Datos que tengamos disponibles, cada cual con su diskgroup asignado correctamente,
alguna Base no levante si no puede montar los discos previamente.
Veamos que sucede con este ejemplo , donde tengo dos nodos de RAC, y Dos Bases.
En el primer nodo la instancia de Base primer base levanto sin problemas, mientras que la segunda base , solo pudo levanta la instancia del primer nodo.
[oracle@saturno02 bin]$ srvctl start database -d DARPRO PRKP-1001 : Error starting instance DARPRO1 on node saturno01 CRS-0215: Could not start resource 'ora.DARPRO.DARPRO1.inst'.
Cuando trabajamos en un ambiente de alta disponibilidad como es el RAC de Oracle, podemos tener varias instancias de una misma base standby.
Podemos poner de Ejemplo un sitio primario como TEST y otro secundario como TESTDG.
La instalacion cuenta con tres nodos para cada sitio.
Entonces podemos decir que contamos con el siguinete escenario:
Cuando trabajamos con el DG BROKER, y perdemos la instancia dataguard TESTDG2 que esta aplicando, automaticamente el broker switchea al primer nodo ( o al que se encuentre disponible en caso de tener mas nodos ) y comienza aplicar en la instancia TESTDG1.
Para poder hacer una standby de forma manual sin tener que recurrir al duplicate database for standby,
podemos usar la forma tradicional.
Para ello como paso previo vamos a setear los parametros que sean necesarios necesarios.
Una vez que tenemos las configuraciones en forma correcta tomamos un backup y luego generamos un controlfile en la base primaria para la base standby.
run {
allocate channel disk1 device type disk
format '/u03/rman_database_backup/STBYcontrolfile.ctl';
backup current controlfile for standby;
}
Una vez que tenemos el backup tanto con el controlfile standby, pasamos del sitio primario al secundario.
[oracle@sdat0101lx]$ ls STBYcontrolfile.ctl JVPAR_t679670423_s345_p1_dbf JVPAR_t679671275_s347_p1_arc JVPAR_t679671249_s346_p1_dbf JVPAR_t679671344_s348_p1_ctl [oracle@sdat0101lx]$ scp STBYcontrolfile.ctl oracle@nodo1jvarlx:/u03/rman_database_backup/ oracle@nodo1jvarlx's password: STBYcontrolfile.ctl
Un ARCHIVE GAP, es una serie de archive redo log files que se crea cuando la base no es capaz de aplicar el siguiente REDO, generado por la base primaria.
Un GAP ocurre cuando:
Cuando reanudamos la transmision por que recuperamos la conexion de red, los servicios de transporte de REDO detectan automaticamente el REDO GAP e intenta resolverlo, enviando un pedido del REDO faltante al sitio primario.
Que tiempo puede llevar resolver un problema de este tipo ?
Cito la documentacion oficial del Oracle:
" El tiempo necesario para resolver un REDO GAP es directamente proporcional al tamaño de GAP e inversamente proporcional al rendimiento efectivo del enlace de red entre la base de datos redo_source y la redo_transport_destination ".
Cuando trabajamos con un sitio de contingencia, tenemos que estar atentos a que en el site donde radica la base stanby se esten aplicando los logs.
Para ello podemos tener algunas herramientas desde el grid control cuando tenemos el broker configurado, donde podemos monitorear varias cosas como si hay logs encolados o si hay gaps. Tambien si nos esta faltando un archive.
