Índice agrupado en SQL Server frente a tablas organizadas de índice en Oracle

Estoy haciendo la transición como desarrollador de bases de datos de SQL Server a Oracle y encontré algunos recursos fantásticos aquí ( ¿Cómo hacer una transición de SQL Server DBA a Oracle? Y como DBA, ¿cómo haría para hacer la transición de Oracle a SQL Server? ? ) pero estoy teniendo dificultades para encontrar buena información sobre el uso de tablas organizadas de índices en Oracle.

En mi vida anterior, hicimos un uso extenso de índices agrupados en SQL Server en nuestro datamart OLTP-ish con gran éxito. ¿Las tablas organizadas por índice son útiles como herramienta en Oracle?

Si está haciendo la transición de SQL Server a Oracle, le aconsejaría que pruebe las tablas de montón al principio porque son la forma estándar de almacenar datos en Oracle. Para la mayoría de las cargas de trabajo, las tablas de montón con índices regulares en Oracle son las formas más equilibradas de almacenamiento con respecto al DML y el rendimiento de las consultas.

Si más tarde descubre que tiene problemas de rendimiento o cuello de botella, debe buscar métodos de almacenamiento avanzados especializados, como IOT, particiones, clústeres, índices de clave inversa, etc.

Con respecto a IOT en particular, desaconsejaría su uso generalizado porque hay muchas "trampas" en las que es posible que no desee entrar como principiante:

• IOT no tiene rowid real (porque no hay una tabla per se).
• en consecuencia, los índices secundarios en IOT no tienen punteros verdaderos a las filas, sino solo meras conjeturas que pueden conducir a escaneos de índices ineficientes.
• Algunas características están deshabilitadas en IOT, como columnas virtuales , compresión de tablas , particionamiento compuesto.
• En la creación, debe decidir dónde almacenar las columnas que no son de índice (en línea o en un segmento de desbordamiento), lo que puede conducir a un rendimiento desastroso para algunas consultas.

Las IOT en Oracle no son lo mismo que los índices agrupados en SS porque las estadísticas de Oracle incluyen la dispersión física de las filas, mientras que SS no incluye la ubicación física en sus estadísticas. Consulte este debate entre Lewis y Fritchey sobre estadísticas en Oracle y SQL Server para obtener más información. ( http://www.red-gate.com/products/oracle-development/deployment-suite-for-oracle/education/webinars/webinar-statistics-oracle-sql-server-jonathan-lewis ) Es por eso que un grupo El índice en SS es mejor que un montón. El índice agrupado agrega datos de ubicación física a las estadísticas. Los IOT son buenos cuando sabe que el índice proporciona la colocación de filas de datos que se buscarán, por ejemplo, el índice en order_date y el cliente para una tabla de pedidos sería un buen IOT.

Vincent destaca algunos puntos importantes de las advertencias de los IOT, pero también puede obtener algunos beneficios significativos de ellos.

Personalmente, creo que están significativamente infrautilizados en Oracle y deberían considerarse mucho más ampliamente, no solo como una posible solución a los problemas de rendimiento. Como tiene que volver a crear la tabla para convertir entre IOT y el montón, este es un cambio que es poco probable que ocurra en una base de datos siempre muy activa, a menos que los problemas de rendimiento sean graves.

Martin Widlake tiene una gran serie de publicaciones sobre IOT. Hay algunos beneficios importantes que puede obtener al usarlos:

• Reduce significativamente las lecturas físicas y lógicas de IO
• Uso más eficiente de la memoria caché del búfer, que puede beneficiar el rendimiento de todo el sistema.
• Espacio ahorrado ya que solo está manteniendo un índice, no una tabla también (a menos que tenga segmentos de desbordamiento)

Sin embargo, para obtener estos beneficios, necesita tablas en las que (casi) siempre incluya las columnas iniciales de la clave principal en las consultas y es probable que obtenga varias filas a la vez. Algunos ejemplos comunes de tales tablas son:

• Detalles maestros múltiples como se encuentran a menudo en pedidos: artículos de pedido, facturas, líneas de factura, etc.
• Tablas de resolución de muchos a muchos que generalmente se consultan "unidireccional". Por ejemplo, en una customer_addressestabla, es mucho más común encontrar todas las direcciones de un cliente, en lugar de todos los clientes de una dirección.

Una desventaja es que la inserción de datos es más lenta, por lo que debe sopesar los costos y beneficios. En última instancia, se trata de conocer sus datos y comprender cómo se utilizarán, lo que debería guiar la decisión.