Índice agrupado no SQL Server vs tabelas organizadas de índice no Oracle

Estou fazendo a transição como desenvolvedor de banco de dados do SQL Server para Oracle e já encontrei alguns recursos fantásticos aqui ( como fazer a transição do DBA do SQL Server para o Oracle? E como DBA, como eu faria a transição do Oracle para o SQL Server ? ), mas estou com dificuldade para encontrar boas informações sobre o uso de tabelas organizadas por índice no Oracle.

Na minha vida anterior, fizemos amplo uso de índices clusterizados no SQL Server em nosso datamart OLTP-ish com grande sucesso. As tabelas organizadas de índice são uma ferramenta útil no Oracle?

Se você estiver fazendo a transição do SQL Server para o Oracle, aconselho tentar as tabelas de heap primeiro, porque elas são a forma padrão de armazenamento de dados no Oracle. Para a maioria das cargas de trabalho, as tabelas de heap com índices regulares no Oracle são as formas mais equilibradas de armazenamento em relação ao desempenho de consultas e DML.

Se, posteriormente, você descobrir que tem problemas de desempenho ou gargalo, procure métodos avançados de armazenamento especializados, como IOT, particionamento, clusters, índices de chave reversa, etc.

Em relação à IOT em particular, eu desaconselharia seu uso generalizado, porque existem muitas "dicas" que você talvez não queira entrar como iniciante:

• O IOT não possui um rowid real (porque não há tabela em si).
• consequentemente, os índices secundários no IOT não têm indicadores verdadeiros para as linhas, mas apenas meras suposições que podem levar a verificações ineficientes do índice.
• Alguns recursos estão desativados em IOTs, como colunas virtuais , compactação de tabela , particionamento composto.
• Você precisa decidir na criação onde armazenar as colunas que não são de índice (em linha ou em um segmento de estouro), potencialmente levando a um desempenho desastroso para algumas consultas.

As IOTs no Oracle não são exatamente iguais aos índices clusterizados no SS, porque as estatísticas do Oracle incluem a dispersão física de linhas, enquanto o SS não inclui a localização física em suas estatísticas. Veja este debate entre Lewis e Fritchey sobre estatística no Oracle e Sql Server para obter mais informações. ( http://www.red-gate.com/products/oracle-development/deployment-suite-for-oracle/education/webinars/webinar-statistics-oracle-sql-server-jonathan-lewis ) É por isso que um cluster O índice em SS é melhor que um heap. O índice clusterizado adiciona dados de localização física às estatísticas. As IOTs são boas quando você sabe que o índice fornece a colocação de linhas de dados que serão pesquisadas; por exemplo, o índice em date_date e cliente para uma tabela de pedidos seria uma boa IOT.

Vincent faz alguns pontos importantes das advertências das IOTs, mas você também pode obter alguns benefícios significativos.

Pessoalmente, acho que eles são significativamente subutilizados no Oracle e devem ser considerados muito mais amplamente - não apenas a solução possível para problemas de desempenho. Como você precisa recriar a tabela para converter entre IOT e heap, é improvável que isso ocorra em um banco de dados sempre ativo e muito usado, a menos que os problemas de desempenho sejam graves.

Martin Widlake tem uma ótima série de posts sobre IOTs. Existem alguns benefícios significativos que você pode obter usando-os:

• Reduza significativamente as leituras físicas e lógicas de E / S
• Uso mais eficiente do cache do buffer, o que pode beneficiar o desempenho em todo o sistema
• Economizou espaço, pois você está apenas mantendo um índice, não uma tabela também (a menos que você tenha segmentos excedentes)

No entanto, para obter esses benefícios, você precisa de tabelas em que (quase) sempre inclui as colunas principais da chave primária nas consultas e é provável que você esteja buscando várias linhas ao mesmo tempo. Alguns exemplos comuns dessas tabelas são:

• Detalhes mestre-múltiplos, como é freqüentemente encontrado em pedidos - itens de pedidos, faturas - linhas de faturas etc.
• Tabelas de resolução muitos-para-muitos que normalmente são consultadas "unidirecional". Por exemplo, em uma customer_addressestabela, é muito mais comum encontrar todos os endereços de um cliente, em vez de todos os clientes de um endereço.

Uma desvantagem é que a inserção de dados é mais lenta, portanto, é necessário ponderar os custos e benefícios. Por fim, tudo se resume a conhecer seus dados e entender como eles devem ser usados, o que deve orientar a decisão.