Estamos construindo um data warehouse (e também alguns data marts) em nossa organização. Minhas habilidades de DBA têm sido principalmente em aplicativos do tipo OLTP, mas estou mudando para o suporte OLAP para nossa organização.
Recentemente, encontramos um problema em que um de nossos programas ETL (neste caso, é um Message Driven Bean escrito em Java) está usando o nível de isolamento Repeatable Read (RR). Por causa disso, eles estavam se deparando com fechaduras. Eu obviamente questiono por que o RR estava sendo usado. ( EDIT: Originalmente pensei em RR no lado DB2, mas descobri que era RR no lado JDBC, que mapeia para RS no lado DB2. Desde então, também tentamos RC no lado JDBC, que é CS no lado DB2 . Isso parece ter resolvido alguns dos problemas de bloqueio.)
Então comecei a pesquisar quais deveriam ser os níveis de isolamento sugeridos para armazenamento de dados, tanto do lado do feed/fonte quanto do lado da recuperação.
Eu realmente não consigo encontrar muito. Eu encontrei alguns artigos que mencionavam leitura não confirmada (UR) sendo bom para o lado da consulta/recuperação, mas nada sobre o lado da alimentação. Eu estava pensando que a estabilidade do cursor (CS) ou a maior estabilidade de leitura (RS) deveria ser usada. Eu ficaria do lado do CS, mas talvez isso esteja contaminado pelo pensamento OLTP?
No nosso caso, o feed principal do nosso armazém agora é feito "em tempo real" usando filas de mensagens Java. A recuperação do warehouse será feita com a ferramenta ETL (DataStage no nosso caso), provavelmente iniciada como trabalhos noturnos (alguns para relatórios diários, outros para relatórios mensais ou trimestrais). Esses relatórios serão baseados em nossos mercados. Portanto, embora o warehouse possa ser alimentado "em tempo real", ele não será lido ou consultado ativamente (pelo menos não agora).
Concedido, usamos o DB2 9.7 FP 4 (e esperamos migrar para 10.1 no próximo ano) e algumas das especificidades podem diferir de acordo com o fornecedor, mas quais níveis de isolamento você recomenda que os DBAs armazenem para feeds e leituras e por quê?
Além disso, qualquer contribuição sobre os níveis de isolamento para mercados seria apreciada.
EDIT: Apenas para facilitar as comparações de outros fornecedores. Aqui está a tabela de nomes de nível de isolamento do DB2 conforme mapeados para os níveis de isolamento JDBC. (Isso de acordo com o livro Understanding DB2: Learning Visually By Example e, portanto, copyright da IBM.)
+------------------------------+-----------------------+ | JDBC | DB2 | +------------------------------+-----------------------+ | TRANSACTION_READ_UNCOMMITTED | Uncommitted Read (UR) | +------------------------------+-----------------------+ | TRANSACTION_READ_COMMITTED | Cursor Stability (CS) | +------------------------------+-----------------------+ | TRANSACTION_REPEATABLE_READ | Read Stability (RS) | +------------------------------+-----------------------+ | TRANSACTION_SERIALIZABLE | Repeatable Read (RR) | +------------------------------+-----------------------+
Para a maioria dos bancos de dados, incluindo Data Warehouses, Read Committed é um nível de isolamento suficiente. Eu não usaria Read Uncommitted devido à possibilidade de respostas incorretas. No SQL Server, também podemos adicionar Isolamento de instantâneo confirmado por leitura. Isso versões linhas e evita que as consultas sejam bloqueadas por atualizações. Não sei se você tem algo semelhante no DB2.
Não tenho certeza se o DB2 escolhe automaticamente o nível de isolamento mais compatível se você defini-lo como modo 'somente leitura', mas no MS SQL Server ele o faz. Você pode tê-lo como 'somente leitura' até pouco antes de seus trabalhos serem executados. Dessa forma, você tem certeza de que alguém não fará uma ATUALIZAÇÃO em um enorme data mart e os problemas de bloqueio/bloqueio serão desativados pelo mecanismo, pois ninguém terá acesso para gravar nele de qualquer maneira.
Definir os níveis de isolamento para READ UNCOMMITTED, como Andy apontou, pode ter efeitos adversos, mas seus leitores não bloquearão os escritores e vice-versa. Se você fizer COUNT (*), verá resultados potencialmente muito diferentes, mas isso realmente depende do seu tempo de carregamento e padrões.
Quanto tempo leva uma carga típica noturna e mensal?