Josh Smeaton's questions

Estive lendo este artigo , discutindo os benefícios, vantagens e desvantagens e possíveis problemas com índices de bitmap. É mencionado:

Além disso, lembre-se de que os índices de bitmap são adequados apenas para tabelas estáticas e exibições materializadas que são atualizadas à noite e reconstruídas após o carregamento da linha em lote. Se suas tabelas não forem somente leitura durante o tempo de consulta, NÃO considere o uso de índices de bitmap!

A maioria de nossas visualizações materializadas é atualizada todas as noites usando o método de atualização rápida. A citação acima significa que o MV deve ser reconstruído ou que os índices devem ser reconstruídos?

Eu tenho uma tabela que armazena um timestamp unix. Para consultar isso como uma data, estou tentando converter esse carimbo de data/hora em um tipo de data e hora em uma exibição. Infelizmente, só consigo obter a parte DATE.

Este link descreve como fazer a conversão, mas requer a alteração nls_date_formatpara incluir a parte do tempo. O padrão atualmente mostra apenas a parte da data. Preciso da data e hora.

Infelizmente, essa solução só funciona em nível de sessão. Como desenvolvedor, prefiro não ter que correr para nosso provedor de serviços gerenciados para pedir que alterem o valor no nível do banco de dados - especialmente porque isso pode afetar outros aplicativos.

Existe uma maneira de converter o timestamp, em sql, para um datetime sem modificar o sistema?

Assim como a pergunta pede; é possível particionar uma tabela verticalmente de forma transparente, usando partições virtuais? Eu imagino se fosse possível, que as colunas seriam apenas armazenadas em espaços de tabela separados ou algo assim.

Em meu ambiente específico, temos um servidor de aplicativos que grava em lote uma grande quantidade de dados a cada 15 minutos ou mais. Há muito mais dados do que nossos aplicativos de relatórios precisam. A tabela de fatos primária tem aproximadamente 50 colunas. Usamos cerca de 10 deles.

Existe algum cenário (mesmo que não existam partições verticais virtuais) em que tal esquema possa melhorar o desempenho? Eu imagino que ter seus dados divididos em vários espaços de tabela (e, portanto, potencialmente em vários discos) melhoraria os tempos de busca.

No momento, estou criando logs de visualização materializada em várias tabelas para oferecer suporte a visualizações materializadas com FAST REFRESH. As visualizações materializadas que estamos criando contêm aproximadamente 30 colunas de várias tabelas. Uma de nossas tabelas de fatos contém cerca de 15 colunas que serão usadas em uma visualização materializada.

É necessário enumerar todas as colunas da tabela base que serão solicitadas na MV ao criar o MV Log?

CREATE MATERIALIZED VIEW LOG ON SCHEMA.TABLE_A 
  WITH ROWID, PRIMARY KEY, SEQUENCE (COL1, COL2, COL3, ..., COL48)
  INCLUDING NEW VALUES;

O acima é um exemplo de como estou criando o Log MV. Admito que o que foi dito acima é resultado de tentativa e erro, sem um entendimento completo de como cada componente da declaração funciona (eu entendo mais).

Em que circunstâncias é necessário que eu defina quais colunas devem ser incluídas no log de VM?

Algumas visualizações materializadas serão apenas uma junção entre várias tabelas. Outros incluirão agregações, agrupamentos, somas, etc.

Temos um data warehouse locado sobre o qual estamos fazendo relatórios. As consultas estão começando a demorar muito, e estamos procurando opções para reduzir isso. Há dois pensamentos no momento.

1. Crie tabelas agregadas específicas do inquilino e consulte-as.

2. Particionar horizontalmente os dados com base no inquilino.

A primeira opção significa que, para cada novo locatário integrado, precisaremos criar um novo conjunto de tabelas. Isso não é tão difícil, pois a inscrição de um novo inquilino vem com algumas semanas de antecedência, e a falta de relatórios será revelada no início, se esquecermos.

Particionar os dados para mim parece uma abordagem melhor, já que não estamos duplicando os dados. Não precisamos depender de um processo para transferir novos dados para as tabelas agregadas.

Eu estou querendo saber qual dessas opções seria melhor, se alguém já teve experiências semelhantes antes. O particionamento dos dados realmente ajuda? Ou não seria muito diferente de deixar todos os dados em um 'espaço'?

E, com o Oracle 10g, como particionar dados horizontalmente? Se eu tivesse a seguinte tabela:

TABLE Transaction(id, tenant_id, a, b, c, d)

Iremos migrar para o Oracle 11g em breve, então qualquer diferença no particionamento entre as versões será bem-vinda.

(Observação: tentei usar uma tag de particionamento, mas não o suficiente, se alguém pudesse adicionar uma tag, seria legal)