¿Cómo mover ocr y vdisk a nuevo disk array?

No hace mucho, uno de mis clientes inició el proceso de migración de su disk storage system, desde EMC CX4 hacia EMC VNX. Ellos tienen sus bases de datos operando con Oracle RAC 11.2.0.3, por lo que siguieron el procedimiento de agregar LUNs del nuevo EMC VNX en los diskgroups de datos, para luego retirar los LUNs del antiguo EMC CX4, aprovechando el rebalanceo automático que hace ASM al agregarle y removerle discos. Hasta aquí todo bien, pero quedaba el trabajo sobre el diskgroup que contiene el ocr, voting disks y spfile de ASM, llamado en este caso OCR, para el cual el procedimiento no es tan simple como agregar y retirar discos. A continuación les mostraré en detalle el procedimiento que seguí para concluir con este último paso en la migración de disk storage system para este diskgroup, cumpliendo el requerimiento expreso del cliente: no suspender el servicio.

Empezaré por mostrarles el escenario sobre el cual se trabajó:

El diskgroup OCR fue creado con redundancia normal, por lo cual es requisito obligatorio emplear 3 discos. El objetivo es que sus contenidos sean ahora trasladados a 3 discos en el nuevo disk array, pero no se puede hacer directamente como en el caso de un diskgroup de datos, básicamente debido a los voting disk.

El ocr y el spfile de ASM son archivos que se distribuyen entre los discos que constituyen el diskgroup sobre el cual residen, pero Oracle crea un voting disk idéntico en cada disco del diskgroup. Así, al agregar mas discos al diskgroup, el ocr y el spfile son candidatos a ser redistribuidos entre todos los discos, pero los voting disk no, se quedan en sus discos originales, por lo que requieren de un tratamiento especial.

El Note 428681.1, OCR / Vote disk Maintenance Operations: (ADD/REMOVE/REPLACE/MOVE), tiene el detalle de lo que sebe hacer en diversos escenarios, de cuya lectura queda claro que no es posible agregar mas voting disks, sino solamente moverlos a otro diskgroup. Por esta razón se solicitó la creación de 3 nuevos LUNs, sobre los cuales se crearía el diskgroup que albergaría temporalmente a los voting disk, de forma que quedara algo así:

Luego que los LUNs estuvieron provisionados y debidamente asignados a todos los nodos del RAC, se procedió a la creación del diskgroup VDISK, mediante el utilitario ASMCA.

Con esto ya estamos listos para el paso inicial: el movimiento de voting disks.

[oracle@rac1]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   1e56372cc94a4f92bfd9952beef36a5b (/dev/rhdiskpower3) [OCR]
 2. ONLINE   570dd695f7ea4f08bf86d92adc2a2343 (/dev/rhdiskpower1) [OCR]
 3. ONLINE   027f719d79914f72bfc1fdfb3098209b (/dev/rhdiskpower2) [OCR]
Located 3 voting disk(s).

[oracle@rac1]$ crsctl replace votedisk +VDISK
Successful addition of voting disk 42cd3a1355714febbf8b8be58da5d277.
Successful addition of voting disk 95b0b904a7844f6bbf35881a7fd545f6.
Successful addition of voting disk 189d6f4cba754fc6bf1d8f94fd70fe89.
Successful deletion of voting disk 1e56372cc94a4f92bfd9952beef36a5b.
Successful deletion of voting disk 570dd695f7ea4f08bf86d92adc2a2343.
Successful deletion of voting disk 027f719d79914f72bfc1fdfb3098209b.
Successfully replaced voting disk group with +VDISK.
CRS-4266: Voting file(s) successfully replaced

[oracle@rac1]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   42cd3a1355714febbf8b8be58da5d277 (/dev/rhdiskpower57) [VDISK]
 2. ONLINE   95b0b904a7844f6bbf35881a7fd545f6 (/dev/rhdiskpower130) [VDISK]
 3. ONLINE   189d6f4cba754fc6bf1d8f94fd70fe89 (/dev/rhdiskpower90) [VDISK]
Located 3 voting disk(s).

Ayudados con el utilitario crsctl, hemos trasladado los voting disks desde el diskgroup OCR hacia el diskgroup VDISK, siendo el escenario actual:

Ahora que el diskgroup OCR contiene solamente el ocr y el spfile de ASM, ya es posible recurrir al rebalanceo de ASM, por lo que procedemos a agregarle los LUNs provisionados en el disk array nuevo, empleando nuevamente el utilitario ASMCA.

Luego de agregar los 3 LUNs del nuevo disk array, la configuración es:

Ahora ya es posible retirar los discos del disk array antiguo, siempre apoyados con ASMCA.

Con los LUNs antiguos ya removidos, la nueva situación es:

Ahora que los contenidos del diskgroup OCR residen exclusivamente sobre LUNs del nuevo array disk, es hora de retornar los voting disks a su diskgroup original.

[oracle@rac1]$ crsctl replace votedisk +OCR
Successful addition of voting disk 5385fdac3eb44f96bf206fc7cce7fe48.
Successful addition of voting disk a4a5d6afbd064fa2bffe306654b0f3ac.
Successful addition of voting disk 2cbc13a0ff444fd7bf79670b75fe42c4.
Successful deletion of voting disk 42cd3a1355714febbf8b8be58da5d277.
Successful deletion of voting disk 95b0b904a7844f6bbf35881a7fd545f6.
Successful deletion of voting disk 189d6f4cba754fc6bf1d8f94fd70fe89.
Successfully replaced voting disk group with +OCR.
CRS-4266: Voting file(s) successfully replaced

[oracle@rac1]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   5385fdac3eb44f96bf206fc7cce7fe48 (/dev/rhdiskpower1002) [OCR]
 2. ONLINE   a4a5d6afbd064fa2bffe306654b0f3ac (/dev/rhdiskpower1001) [OCR]
 3. ONLINE   2cbc13a0ff444fd7bf79670b75fe42c4 (/dev/rhdiskpower1000) [OCR]
Located 3 voting disk(s).

Finalmente hemos llegado al siguiente escenario:

En este momento ya tenemos tanto el ocr, el spfile y los voting disks en el diskgroup OCR, usando únicamente LUNs del nuevo disk storage system EMC VNX, por lo que es posible eliminar el diskgroup VDISK, ya no necesitamos más de él.

Con esto podemos dar por concluida la tarea de movimiento de los contenidos del diskgroup OCR (ocr, voting disks, spfile de ASM), hacia el nuevo disk array EMC VNX, sin suspensión alguna del servicio y en muy pocos minutos. Desde luego, el procedimiento fue previamente probado en un ambiente virtualizado, pues una cosa es lo que dice la documentación y otra la que pasa en la vida real, por lo que es altamente recomendable que Uds. tambien lo hagan, recuerden que cada instalacion tiene su particularidades, así que mejor no correr riesgos innecesarios. Será hasta la próxima amigos!

Post Relacionados:

• Actualizando ASM y registrándolo en OEM
• Bye bye raw device, ¡bienvenido ASM!
• Trasladando la Base de Datos hacia ASM
• Migrando la base de datos a ASM, la forma fácil

Siga leyendo >>

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!

OOW 2012, allá voy!

Cada año se realiza el Oracle Open World, al cual somos cordialmente invitados todos los Oracle ACE. Pero nunca faltaba algún contratiempo (léase proyecto en marcha con plazos ajustados) que me obligaba a postergar mi asistencia, pero al iniciar este año tomé la decisión de asistir sí o sí.

Desde Junio hice la compra de los respectivos boletos de avión, que -gracias a los KM acumulados- me salieron gratis! Y ya que entraba en la onda del low budget, opté por reservar habitación en el Park Hotel de San Francisco, por solo US$450 la semana!, una ganga considerando que en San Francisco no es nada barato el alojamiento, y más aún cuando 50,000 personas llegan de golpe casi el mismo día y pugnan por tener un alojamiento cercano al Moscone Center, lugar donde se desarrolla el OOW, y el Park Plaza está a unas pocas cuadras, tan cerca que puedo llegar incluso a pie.

Resuelto el problema de cómo llegar y dónde alojarme, venía la tarea de escoger entre los cientos de presentaciones disponibles, tarea nada fácil desde luego. Luego de revisar y revisar, terminé seleccionando lo que me pareció más cercano a lo que vengo desarrollando regularmente: Tuning de Base de Datos y Aplicaciones, y soluciones de Alta Disponibilidad y Contingencia.

Aparte de las presentaciones técnicas, Larry Ellison siempre busca robarse el show, y este año no sería la excepción: hay fuertes rumores de que nos daria la sorpresa con el lanzamiento de Oracle 12c Database, nada mal, cruzo los dedos para que así sea.

Y como no todo es Oracle, aprovecharé a tomar una semana de descanso, para conocer las atracciones principales de San Francisco (Alcatráz, Golden Gate) y probablemente San Diego (Zoo, SeaWorld), y por qué no, para deleitarme con un buen cebiche al estilo peruano en La Mar .

Es todo por el momento amigos, prometo mantenerlos al tanto de las novedades en el OOW (siganme en Twitter @enriqueorbegozo) y a mi retorno retomar los Posts técnicos, que buen tiempo he abandonado, hasta la próxima!

Siga leyendo >>

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!

Las paradojas del tiempo

En esta ocasión les voy a contar sobre un problema muy singular y la forma en que fue resuelto, estoy seguro que muchos usuarios de AIX 6.1, y quizás de otras plataformas, deben tener este problema y no lo han notado aún.

La historia se remonta a unos meses atrás, había concluido el upgrade de una base de datos desde Oracle 10.2.0.3 hacia Oracle 11.2.0.2.3, que era la versión más reciente en ese momento, y luego de ello nos percatamos de que los tiempos de respuesta se habían deteriorado, sin explicación alguna.

Como el upgrade incluyó la migración de la base de datos a un nuevo servidor, empezamos a hacer algunas pruebas usando ambos servidores y ambas versiones de Oracle y finalmente logramos reducir el problema al uso de SYSDATE, con los resultados que se muestra a continuación.

DECLARE
  v_dt DATE;
BEGIN
  FOR i IN 1 .. 1000000 LOOP
    SELECT SYSDATE INTO v_dt FROM dual;
  END LOOP;
END;
/

Antiguo servidor
10.2.0.3:
Elapsed: 00:00:32.17

11.2.0.2.3:
Elapsed: 00:00:41.09

Nuevo servidor
11.2.0.2.3:
Elapsed: 00:00:56.89

Noten como en el antiguo computador, Oracle 11.2 toma 28% más tiempo en procesar que Oracle 10.2, y en el nuevo computador la situación es más grave aún pues toma 78% más tiempo, esto considerando que el nuevo computador es el doble de rápido que el antiguo!

Como el problema era evidente recurrimos a Oracle Support, quienes finalmente nos recomendaron hacer upgrade al reciente Oracle 11.2.0.3, lo que hicimos inicialmente en el antiguo servidor, con el siguiente resultado:

Elapsed: 00:00:32.62

La situación mejoró notablemente y ya se observaban tiempos similares a los que Oracle 10.2.0.3 proporcionaba, así que iniciamos el upgrade del servidor de producción hacia Oracle 11.2.0.3. Grande fue nuestra sorpresa cuando luego de ello encontramos lo siguiente:

Elapsed: 00:00:51.53

La mejora solo fue de 9%, terrible, inexplicable, desalentador. Fue entonces que Oracle sacó su as bajo la manga y nos indicó aplicar el patch para el bug 12596494 GENERALLY HIGHER CPU USAGE IN 11.2.0.2 THAN 10.2.0.4 11.2.0.3.0 IBM AIX on POWER Systems (64-bit), que ya habíamos aplicado en Oracle 11.2.0.2.3 pero que no había sido resuelto aún en 11.2.0.3. Con la esperanza de que finalmente resolveríamos el problema lo aplicamos en el servidor de producción, obteniendo el siguiente resultado:

Elapsed: 00:00:43.43

Aún con el patch aplicado, el tiempo era 34% superior al que Oracle 10.2.0.3 lograba en el antiguo servidor, con procesadores mucho más lentos que el de producción.

Ya se nos habían agotado todas las ideas, pero como bien dicen: cuando está todo más oscuro, es porque está por amanecer, y fue justo en este momento que IBM hizo su aparición: un Ingeniero de IBM de Argentina nos dirigió al APAR IZ86764 PERFORMACE DIFFERENCE WHEN USING OLSON TZ .VS. POSIX TZ:

Problem summary

Doc change noting performance impact when using Olson time zone instead of Posix time zone.

Problem conclusion

There will be new information addeded to the "Miscellaneous tunable parameters" section under "Tunable parameters – Environment variables" in the Performance Management Guide regarding the Olson time zone, basically stating that TZ in AIX 6.1 and later are defaulted to Olson time zone, and may be tuned to POSIX time zone for performance sensitive applications that do not depend on adequately handled changes to time zone rules and daylight saving time.

¡Bingo! Comparando el antiguo y el nuevo servidor encontramos:

[root@old.server]$ oslevel –s
5300-07-00-0000
[root@old.server]$ echo $TZ
EST5 (POSIX)

[root@new.server]$ oslevel –s
6100-06-05-1115
[root@new.server]$ echo $TZ
America/Lima (OLSON)

En efecto, esa era la diferencia entre ambos servidores, el antiguo usaba un TZ del tipo Posix, a diferencia del nuevo, que usaba TZ del tipo Olson, así que de inmediato hicimos el cambio:

/etc/environment
#TZ=America/Lima
TZ=EST5

Y a continuación realizamos la prueba de rigor, con el resultado:

Elapsed: 00:00:17.19

Finalmente logramos que el proceso se ejecutara en menos tiempo, siendo 88% más rápido con respecto a los tiempos observados en el antiguo computador, ¡problema resuelto!

Algún tiempo después he tenido la oportunidad de trabajar con instalaciones similares (AIX 6.1 con Oracle 11.2), en las que venían trabajando con TZ del tipo Olson y sin aplicar patch alguno, por lo que me temo que para la gran mayoría de usuarios de esta combinación, el problema no ha sido notado aún y por consiguiente no tienen el desempeño que podrian tener.

Hasta acá llegamos por ahora, espero que con lo indicado logren obtener mejoras en sus instalaciones, quizás esto ocurre también en otras plataformas, de ser así por favor compartan su experiencia por este medio, les estaremos muy agradecidos, hasta la próxima.

Siga leyendo >>

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!