domingo, 30 de marzo de 2014

Consultas para ver atributos de tablas e índices particionados

Este post es para compartir un par de consultas que uso muy seguido y quiero dejar a mano en el blog, ya que no tengo un área de scripts.

Si usamos habitualmente la línea de comando para administrar una base de datos, tenemos a mano muchos scripts SQL para distintas tareas. Para consultas simples no es tan necesario, como por ejemplo ver los índices de una tabla. Pero cuando trabajamos con tablas particionadas, lleva un poco más volver a escribir esa consulta que nos muestra todos los datos que nos interesa. Tener a mano el script SQL es útil para ahorrarnos escribirlo de nuevo cada vez.

Actualmente hay muchas herramientas gráficas/web de administración que nos hace dejar de lado usar este tipo de scripts para consultar metadata de la base de datos. Usar scripts también puede ser un hábito adquirido con el tiempo (señal del paso del tiempo :)), aunque hay casos en que es necesario. Uno de ellos es cuando hay firewalls o medidas de seguridad que solo permiten acceso a la base de datos mediante una terminal. Aunque los firewalls se puedan esquivar usando túneles con ssh para utilitarios cliente/servidor (como SQL Developer o MySQL Workbench), para utilitarios que publican un acceso web es más complicado (Grid Control), y ahí vuelven a tener sentido los scripts.

Así que hecha la introducción, estos son un par de scripts útiles para ver información de una tabla particionada y sus índices. Cuando no hay particiones, estos datos se pueden sacar con una consulta simple sobre DBA_TABLES y DBA_IND_COLUMNS sin mucha complicación.

Para ilustrarlo mejor, un ejemplo usando estas tablas:
select table_name, num_rows from dba_tables where table_name like 'BIGTBL%'; TABLE_NAME NUM_ROWS ------------------------------ ---------- BIGTBL_PART_FACT 34718511 BIGTBL_PART_ID 41529989 BIGTBL 5931843 3 rows selected.

Así vemos por separado sus particiones:
break on t.table_NAME on t.partitioning_type on t.partition_count on t.status select t.table_NAME, t.partitioning_type tipo, t.partition_count particiones, t.status, c.COLUMN_NAME, c.COLUMN_POSITION from DBA_PART_KEY_COLUMNS c, dbA_part_tables t where t.table_name = c.name and c.owner = t.owner and t.table_name like 'BIGTBL%' order by c.name, c.COLUMN_POSITION; TABLE_NAME TIPO PARTICIONES STATUS COLUMN_NAME COLUMN_POSITION ------------------------------ --------- ----------- -------- -------------------- --------------- BIGTBL_PART_FACT RANGE 50 VALID NRO_FACT 1 BIGTBL_PART_ID RANGE 50 VALID ID 1 2 rows selected.

Juntamos ambas consultas en una sola:
col part_col for a30 select t.table_NAME, t.num_rows, p.partitioning_type particion, p.partition_count "#part", p.status, c.COLUMN_NAME part_col, c.COLUMN_POSITION pos from dbA_tables t, DBA_PART_KEY_COLUMNS c, dbA_part_tables p where t.table_name = p.table_name(+) and t.owner=p.owner(+) and t.table_name = c.name(+) and t.owner = c.owner(+) and t.table_name like 'BIGTBL%' order by t.table_name, c.COLUMN_POSITION; TABLE_NAME NUM_ROWS PARTICION #part STATUS PART_COL POS ------------------------------ ---------- --------- ---------- -------- ------------------------------ ---------- BIGTBL_PART_FACT 34718511 RANGE 50 VALID NRO_FACT 1 BIGTBL_PART_ID 41529989 RANGE 50 VALID ID 1 BIGTBL 5931843 3 rows selected.

La misma idea aplicada a los índices nos lleva a esta consulta, para ver los índices, saber si están particionados y algún dato más:
col index_name for a30 select c.index_name, uniqueness, i.partitioned, p.partitioning_type tipo, locality, c.column_name, column_position pos from dba_ind_columns c, dba_indexes i, dba_part_indexes p where i.index_name=c.index_name and c.index_owner=i.owner and c.table_name=i.table_name and c.table_owner=i.table_owner and i.owner=p.owner(+) and i.index_name=p.index_name(+) and i.table_name=p.table_name(+) and c.table_name='BIGTBL_PART_ID' order by c.index_name, c.column_position; INDEX_NAME UNIQUENES PAR TIPO LOCALI COLUMN_NAME POS ------------------------------ --------- --- --------- ------ -------------------- ---------- IDX_BIGTBL_PART_2 NONUNIQUE NO COD_DOC 1 IDX_BIGTBL_PART_2 NONUNIQUE NO COD_LOCAL 2 IDX_BIGTBL_PART_ID UNIQUE YES RANGE LOCAL NRO_FACT 1 3 rows selected.

Espero les sea útil

sábado, 29 de marzo de 2014

Preguntas y respuestas de la presentación sobre RAC

Muchas gracias a todos los que me acompañaron en la presentación sobre Oracle RAC hace unos días.
Hubo varias preguntas al final, y algunos asistentes me pidieron que les enviara referencias. No tuve tiempo de tomar nota de quién hizo esas preguntas antes de que se cerrara la sesión, así que dejo acá las respuestas, que además sirven para ampliar el material usado en la presentación.
Transcribo las preguntas de memoria, así que espero que sean lo más parecido posible a la realidad. Y aprovecho a desarrollarlas un poco más.


  • ¿Se necesita Oracle ASM con Oracle RAC 11g?
ASM es la única alternativa si se usa la versión Standard Edition de Oracle.
En Enterprise Edition se permiten alternativas (documentadas en la matriz de certificación en el sitio de soporte), aunque Oracle ASM es la recomendada para la base de datos y los archivos OCR y voting disk usados por clusterware. Este es justamente uno de los puntos fuertes a favor de usar RAC, contar con soporte de todos los componentes de la infraestructura por parte del mismo proveedor, lo que da cierta garantía sobre la integración de las partes y se minimiza el tiempo de resolución de incidentes.
Un buen ejemplo de que siempre es necesario consultar la documentación es que HP Serviceguard Storage Management Suite no aparece soportado en 12.1 y sí lo estaba en 11.2 (junto a otros productos).


  • ¿Recomendaciones para hacer upgrade de RAC 10g a RAC 11g?
Este es un tema que tiene varios puntas. La mejor recomendación podría ser estudiar  la documentación, y en particular el Blog de Upgrade de Oracle, que tiene todo lo que nos puede interesar sobre upgrades. Este es el link al workshop de Upgrade. También el sitio de soporte tiene mucha información sobre el tema, y la más completa es "Upgrade Advisor: Database from 10.2 to 11.2 (Doc ID 251.1)" que incluye muchas referencas a todas las etapas de un proyecto de upgrade.

Si el upgrade incluye usar nuevo hardware, se puede realizar la instalación con tranquilidad sobre el hardware nuevo para luego evaluar estrategias para replicar datos sin afectar el sistema de producción. Más adelante se aclaró que el upgrade sería sobre el mismo hardware, lo que plantea desafíos adicionales:
- se debe validar que la versión del Sistema operativo (SO) permita realizar un upgrade a la nueva versión (hay años de diferencia entre las versiones, y si bien se certifican nuevas versiones de la base de datos con versiones viejas del SO, normalmente requiere parches en el SO que pueden no estar instalados). Si se requieren parches, se agrega complejidad al proceso y posiblemente una ventana adicional de indisponibilidad.
- al trabajar sobre los mismos servidores que soportan un sistema en producción, se debe buscar un procedimiento que minimice el impacto en la disponiblidad del sistema. Por ejemplo, dependiendo de la cantidad de servidores que tenga el cluster, se podría ir quitando de a un servidor y hacer la actualización mientras el resto sigue funcionando (método conocido como rolling upgrade). Un punto importante es que ASM permite rolling upgrades a partir de 11g, por lo que se debe planificar un tiempo de indisponiblidad para realizar esta actualización desde 10g cuando se llegue al último servidor.

Por culminar, algo obvio pero que no está de mas recordarlo: este tipo de trabajo requiere mucha validación previa, por lo que es imprescindible contar con un ambiente de prueba donde realizar el procedimiento de upgrade completo, y se puedan realizar ajustes y automatizar todo lo posible previo a su ejecución en producción.


  • ¿Cómo identificar índices que no se usan?
Esta pregunta tiene que ver con la recomendación de evitar la generación de redo innecesario por tener muchos índices que no se usan.
La respuesta obvia podría ser habilitar la funcionalidad de monitoreo de índices, disponible desde 9i. 
Aunque esta solución es muy simple, no es la mejor porque puede detectar casos que no nos interesan, ya que no registra la frecuencia con que fueron usados. Por ejemplo, un proceso agendado que ejecute por la noche y no tenga impacto en el uso del sistema puede ser el único que use un índice.
Otro aspecto importante para buscar oportunidades de reducir la generación de redo es eliminar índices redundantes, cosa que no tiene mucho que ver con esta detección índices usados.
En los foros de OTN hay varias preguntas similares, y esta es un buen ejemplo con varias respuestas que incluyen todos estos detalles.
Otro enfoque para identificar el uso de índices junto a la frecuencia con que son usados es aprovechar los datos capturados por AWR, si tenemos la versión Oracle Enterprise Edition y la licencia del Diagnostic Pack. Esto es algo bastante comentado en la comunidad, y por ejemplo en este muy completo post se pueden ver scripts y ejemplos de como obtener esta información.


  • ¿ASM puede saturar los discos?
ASM es el intermediario para gestionar los discos, pero el acceso a los bloques en disco lo hace el proceso de usuario que lo necesita (y los procesos de la base para escribir). Entonces no hay overhead en el acceso a disco asociado al uso de ASM.
El rendimiento de los discos va a ser el mismo que se pueda obtener por fuera de ASM, con acceso directo desde el sistema operativo (SO). Una buena nota de soporte que intenta aclarar esto es "Comparing ASM to Filesystem in benchmarks (Doc ID 1153664.1)".
Cualquier problema en la configuración que los hace visibles al SO y que pueda impactar en su rendimiento se va a extender a cualquier programa que los use. Esto incluye la conectividad al storage y la redundancia (multipath). Un ejemplo análogo es el uso de raid, donde es posible ver configuraciones que no logran la mejor performance, y cualquier filesystem que utilice estos discos va a sufrir su impacto.
Otra interpretación de la pregunta puede ser apuntando a las tareas internas que ejecuta ASM para garantizar la redundancia configurada. Hay operaciones internas de rebalanceo cuando cambia la cantidad de discos disponibles en los disk groups. Cuando ésta ejecuta se agrega actividad sobre la que ya existe en los discos, y se puede controlar su impacto en la performance con el parámetro ASM_POWER_LIMIT. El avance de estas operaciones se puede seguir en la vista GV$ASM_OPERATION

Espero que les sea útil.
Un saludo.

lunes, 10 de marzo de 2014

Presentación sobre Oracle RAC este miércoles

El grupo de interés sobre Oracle Real Application Clusters (RACSIG) desde hace años comparte valiosa información técnica en su sitio web, y organiza presentaciones que se pueden seguir en vivo por internet (webinar o webcast). Es una organización similar a un grupo de usuarios, pero no limitado a un país, sino de alcance global. 

Fui invitado a dar una presentación en español, para inaugurar el contenido de habla hispana, y será este miércoles 12 de marzo a las 13:00 hs de Uruguay (GMT-3). Los detalles aquí.
Para seguir la presentación en vivo, se deben registrar previamente en el sitio, que los llevará a este link.

Esta es una versión actualizada con funcionalidades de las últimas versiones (11g/12c) a la presentación que dí durante el OTN Tour 2011 en Montevideo, Oracle RAC sin sorpresas, donde se repasa lo que implica usar Oracle RAC, los desafíos y recomendaciones de cómo sacarle mejor provecho. 
Este enfoque introductorio intenta facilitar el camino a los técnicos que están evaluando o comenzado a utilizar Oracle RAC, tarea que tiene una larga curva de aprendizaje.

Los espero.

Un saludo.