Chris Aldrich's questions

Acontece que estamos usando o SQL Server 2012 Standard Edition. Também uso os scripts de Ola Hallengren para fornecer uma estrutura fácil e mais flexível para fazer backups e manutenção.

Esta pergunta não é tanto sobre os scripts de Ola, mas sim sobre uma prática recomendada. Sei que a resposta final é "depende dos requisitos da sua empresa". Mas estou tentando buscar o conselho da comunidade sobre a melhor forma de cumprir o que entendo dos requisitos de nossa empresa.

Desejo configurar backups de log de transações a cada 15 minutos. Dessa forma, esperamos não perder mais de 15 minutos de dados. Devo configurar um trabalho que usa ALL_DATABASES? ou é melhor configurar um trabalho para cada banco de dados e iniciá-los todos em paralelo? Pergunto, porque tenho a sensação, com base em como vejo o script de Ola funcionando, de que os backups são iniciados em série. A desvantagem do serial seria que cada backup sucessivo espera até que o outro seja concluído. Isso pode aumentar potencialmente a quantidade de tempo entre os backups (ou seja, mais de 15 minutos). Além disso, minha preocupação seria que uma falha em um backup impedisse que os outros acontecessem, e eu não gostaria que fosse esse o caso. Eu gostaria que os outros continuassem recuando.

Então é verdade que os scripts do Ola são executados em série e também uma falha interrompe os backups sucessivos?

E é melhor ter um trabalho para cada banco de dados? ou um único trabalho que faz tudo? Minha inclinação é para trabalhos separados, mas desejo entender o que os DBAs do SQL Server em geral tendem a fazer.

Eu tenho uma pergunta que está me incomodando, mas eu simplesmente não sei como validá-la. Executamos o DB2 LUW no AIX em nossa loja. Nosso AIX está atualmente em 7.1. Nosso DB2 está em 9,7 FP 4 para a maioria das instalações e 10,5 FP 2 para nossos bancos de dados mais recentes. Temos até instalações mistas (ou seja, 9.7 e 10.5) nas mesmas "caixas".

Nossas caixas são LPARs, é claro, fornecidas a nós por nossos administradores do AIX. Os administradores do AIX também são nossos administradores de armazenamento e, portanto, todos os discos são SAN. Não há muito físico sobre nossos servidores de banco de dados.

O que está me incomodando é qual é o equilíbrio correto de instâncias do DB2 por LPAR? Comecei a ver um comportamento estranho em relação à autoconfiguração do DB2. Em um DEV LPAR temos as seguintes configurações:

Observe que o seguinte é verdadeiro para todas as instâncias: HEALTH_MONé definido como OFF, e AUTO_MAINTé definido como OFFpara cada banco de dados. Permitimos que o Self-Tuning Memory Manager (STMM) esteja ativado por padrão com todos os parâmetros necessários definidos para isso (ou seja, zeros ou AUTOMÁTICO nos parâmetros corretos, o padrão que o DB2 fornece...). Se construirmos um banco de dados OLTP, definimos instance parm MAX_QUERYDEGREEcomo 1e deixamos INTRA_PARALLELcomo NOe db parm DFT_DEGREEcomo 1. Se construirmos um banco de dados OLAP (instância separada), definimos instance parm MAX_QUERYDEGREEto ANYand INTRA_PARALLELto YESe db parm DFT_DEGREEtoANY. Também não tentamos misturar bancos de dados OLAP e OLTP na mesma instância, embora parte da questão seja se devemos misturar as instâncias no mesmo LPAR.....

Aqui está o que temos em um DEV LPAR:

1. A primeira instância é 9.7. Contém alguns bancos de dados OLAP, embora sejam muito pequenos, pois são usados ​​para testar alterações DDL.
2. A segunda instância é 9.7. Contém um banco de dados OLAP "playground" para desenvolvedores. (Este deve ser aposentado na primeira chance que tivermos.)
3. A terceira instância é 10.5. Contém a versão DEV oficial desse banco de dados de playground da instância 2.
4. A quarta instância é 10,5. Banco de dados OLTP com um dicionário de metadados desenvolvido em casa.
5. A quinta instância é 10.5. Banco de dados OLTP usado para dados de pesquisa.
6. A sexta instância é 10,5. Banco de dados ODS (não tenho certeza se é OLTP ou OLAP....) para desenvolvedores vincularem dados de dois sistemas transacionais.

Agora, o disco não é o maior problema, pois é tratado pela SAN. E até a memória e a CPU são virtualizadas por natureza, sendo uma LPAR. Mas eu vi algumas coisas estranhas com a memória.

O único banco de dados OLAP (tanto o playground quanto o DEV oficial) é bastante grande. Os desenvolvedores estão testando o ETL em grandes volumes de dados e estimando o tamanho de sua solicitação oficial para construções QAT e PROD. Desde que um deles começou a crescer, notei que novas construções de instância e novas construções de banco de dados agora têm o STMM desativado por padrão. Posso ligá-lo manualmente, mas o ponto é que acho isso perturbador. Se o STMM está ou não ativado por padrão é decidido pelo DB2 no momento da criação com base nos recursos do sistema. Então, para mim, isso está dizendo que o DB2 não sente que tem recursos adequados para gerenciamento automático, então está tentando limitar a memória na esperança de ganhar pelo menos tanto. (Meu palpite sobre isso.)

Quando discuto isso com os administradores do AIX, eles não parecem pensar que a memória e a CPU são um problema. Eles dizem que não estamos realmente utilizando o que poderíamos ser, então, em sua mente (e estou dizendo isso de forma muito vaga), poderíamos colocar todas as nossas instâncias de desenvolvimento no mesmo LPAR. Ou similar para outros ambientes. Novamente, isso é vago, porque eles entendem o ponto de separação para cenários HA e DR.

De qualquer forma, isso me deixa pensando: há alguma indicação ou orientação entre saber quando você pode adicionar instâncias a um LPAR ou quando deve dividir para outros LPARs? Tenho certeza de que a resposta é "depende", mas estou procurando alguma aproximação ou orientação? Especialmente se eles diferem nas linhas de OLTP e OLAP.

Eu e outro DBA em nossa empresa temos a tarefa de revisar um projeto de banco de dados que um fornecedor desenvolveu para nós. O fornecedor disse que usa Kimball como base para seu design. (NOTA: não estou procurando argumentos de Kimball vs Inmon, etc.) Eles projetaram um mercado com múltiplos fatos e dimensões.

Agora, com toda a justiça, nossa empresa nunca projetou um único mercado. Sempre tivemos os consultores fazendo isso. E nunca fomos mandados para aulas nem nada. Portanto, nosso conhecimento de warehousing/marts/modelagem dimensional etc. é baseado na pouca experiência que temos, no que podemos encontrar na Internet e na autoleitura (temos os livros de Inmon e Kimball e estamos tentando fazer o nosso caminho através deles) .

Agora que o palco está montado para o meu nível de conhecimento, chegamos ao desafio do design.

Existe uma tabela de fatos chamada "Estatísticas de sinistros" (para seguros). E eles estão tentando capturar tanto os pagamentos de sinistros (acumulados até um nível mensal) quanto o dinheiro nas reservas (como uma conta bancária para sinistros). Eles desejam ver os valores mensais para pagamentos (nada demais). Mas eles desejam ver o saldo atual da conta das reservas.

Vou dar um exemplo pictórico.

Digamos que definimos US$ 1.000 em reservas para uma reivindicação. Isso é reservado (portanto, em alguns aspectos, funciona como uma conta bancária).

Em outubro de 2014, ainda não pagamos nada. Então a empresa quer ver os pagamentos e o saldo da reserva no final de outubro.

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------

Então chega novembro. Fazemos pagamentos de $ 100, $ 150 e $ 75 dólares. Eles desejam ver esses valores agregados e a reserva no saldo da seguinte forma:

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------
-      112014  -    325.00 -           675.00 -
-----------------------------------------------

E então digamos que temos zero pagamentos em dezembro e mais $ 200 em janeiro do próximo ano.

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------
-      112014  -    325.00 -           675.00 -
-----------------------------------------------
-      122014  -      0.00 -           675.00 -
-----------------------------------------------
-       12015  -    200.00 -           475.00 -
-----------------------------------------------

Aqui é onde eu luto. Meu entendimento é que a parte de pagamentos está correta. Eles são todos acumulados em um nível mensal dentro de cada registro. Assim, você pode acumular ainda mais, se quiser, para o ano, trimestre etc.

Mas o valor das reservas é diferente. É um equilíbrio. E a empresa quer ver quanto está no saldo a cada mês. Mas você não pode agregar neste campo. Se o fizesse, obteria alguns resultados instáveis.

De alguma forma, isso me parece errado. Mas não posso dizer com sinceridade que modelei o suficiente ou conheço o suficiente. Tudo o que posso dizer é o que sei. E pelo que sei, todos os valores em um Fato devem estar na mesma granularidade.

Ambos os números estão na mesma granularidade de um "mês", mas não são do ponto de vista do que representam. Um é dólares agregados dentro de um mês. O outro é apenas o equilíbrio.

Isso está correto? Eu tenho empurrado para trás neste design. Estou errado em fazer isso? Está tudo bem fazer isso de fato? Ou meu senso de "cheiro de código" de um design ruim é preciso?

Qualquer ajuda seria apreciada. NOTA: por favor, não diga apenas "Deveria ser o caminho X", explique por que deveria ser assim para que eu possa aprender com isso.

EDIT : Bem, aprendi que minha compreensão inicial do fato está errada. A granularidade NÃO é mensal. A granularidade é nível de transação. Isso significa que dentro de MONTH_YEAR (ou seja, realmente é o período do relatório financeiro) haverá várias transações de pagamento e recuperação. Esses serão postados por data ou data de transação. Mas por causa de um relatório anterior que a empresa vê, e também por causa de como os dados são armazenados no sistema legado de onde vem, eles queriam colocar os dados transacionais (uma linha por) e o saldo mensal de reserva (uma linha por mês ).

Depois que aprendi isso, percebi que o problema não era tanto aditivo versus não aditivo, ou mesmo semi-aditivo, mas era grão, que é o que eu suspeitava desde o início. Nossa equipe de DBA discutiu isso com a equipe do projeto e relatou que eles estão tentando colocar dois grãos diferentes no mesmo fato, e isso não foi correto. Que eles deveriam rolar as transações para um nível mensal, permitindo que eles tivessem os pagamentos, as recuperações e o saldo mensal da reserva (ou seja, um fato semi-aditivo) porque tudo seria em um grão mensal. Ou eles precisam encontrar uma maneira de dividir o saldo de reserva em transações para preservar o nível de granulação da transação. Ou eles precisam quebrar o fato em dois fatos. Um pode ser o nível mensal do saldo da reserva. O outro pode estar no nível da transação para os pagamentos e recuperações. (Não há razão para que eles também não possam colocar os pagamentos e recuperações em nível mensal no fato de nível mensal também. Depende apenas das necessidades do negócio.)

Dado o que aprendi, marcarei a resposta de Thomas como a correta. No entanto, sinto que a discussão que comecei com a pergunta original ainda é boa para os outros aprenderem, então deixarei a parte original da minha pergunta intacta. Também pretendo recompensar a resposta de nikadam, pois ela me ensinou muito sobre fatos aditivos, não aditivos e semiaditivos e corrigiu muitos mal-entendidos que eu tinha sobre modelagem dimensional.

Nosso ambiente atualmente é o DB2 9.7 Fix Pack 4 no AIX.

Estou no processo de projetar e codificar alguns procedimentos armazenados SQL PL responsáveis ​​por arquivar dados em um esquema de arquivo e, em seguida, eliminar dados antigos/desnecessários do esquema principal.

Criei alguns tipos definidos pelo usuário (UDTs), especificamente tipos de linha e tipos de cursor. Estou olhando para dividir minha lógica em três procedimentos armazenados. Proc Aseria usado para limpar um determinado conjunto de dados relacionados à minha tabela EVENT principal (ou seja, o EVENTe tudo abaixo dela). Eu realmente não quero que outros possam chamar isso. Eu só quero modularizar a lógica. Proc Biria arquivar dados de EVENT(e outras tabelas) que o usuário final deseja e, em seguida, chamar Proc Apara limpar os dados originais. Proc Cseria usado para procurar EVENTsque poderia ser descartado e, em seguida, chamado Proc Apara o trabalho real.

Agora eu poderia criar tudo isso independente um do outro e, em seguida, implantá-los dessa maneira. Ou....eu poderia usar um módulo. Pelo que entendi, um módulo me permite associar funcionalidades relacionadas (tipos, procs armazenados, funções, etc.) juntos. Ele também me permite decidir quais objetos eu desejo que sejam acessíveis externamente ao módulo, ou seja, podem ser chamados/usados ​​diretamente, versus quais podem ser chamados apenas internos ao módulo (como o caso acima, onde eu poderia ocultar objetos armazenados Proc A, mas permitir Be Cchamá-lo).

Isso soa incrivelmente intrigante. Mas também tem suas desvantagens. Acho que não faz parte de nenhum padrão SQL, mas algo específico do IBM DB2. Mesmo assim, você não pode interagir diretamente com os módulos via Data Studio ou Control Center (além CALLdos procedimentos/funções de face externa). E também não é possível criá-los diretamente no InfoSphere Data Architect da IBM. Então eu teria que manter os DDL's de forma independente.

Portanto, o conceito de módulo parece útil. Posso esconder algumas coisas e escolher o que pode ser chamado para garantir que alguém não faça mau uso de nada.

Mas, dado que não parece ser suportado por ferramentas IBM fora da linha de comando .... Eu estava pensando .... quem usa módulos (especificamente no DB2 LUW)? Alguém? Faz sentido? Caso contrário, existe outra maneira de realizar meu pensamento de modularizar o código enquanto torna os "módulos" inacessíveis para chamadas diretas?

Em primeiro lugar, estamos no Windows e no AIX e estamos usando o DB2 ESE 9.7 FP 4.

Estou tentando determinar dinamicamente se os espaços de tabela são ou não configurados por meio de armazenamento automático ou não (para que possamos criar um script dinâmico de como diminuir a marca d'água alta quando necessário). Posso ver se eles são definidos como SMS ou DMS "nos bastidores" por meio de declarações como db2 list tablespacesou db2 list tablespaces show detail.

Também emiti consultas nas tabelas e exibições do catálogo do sistema (ou seja, select * from syscat.tablespacese select * from sysibm.systablespaces).

Tudo o que posso dizer é que o tablespace é definido como SMS ou DMS. Como posso saber se o tablespace está ou não configurado para armazenamento automático? Sei que deve haver uma maneira de fazer isso dinamicamente, porque se eu usar o IBM Data Studio e visitar a "visualização" dos tablespaces e clicar em propriedades, posso ver se o tablespace é um armazenamento automático ou não. Estou assumindo que deve haver uma configuração ou uma consulta por trás disso.

Apenas imaginando, como descobrimos isso?

Com base em uma pergunta anterior que fiz , estou tentando trabalhar em uma solução conforme recomendado pela resposta de mustaccio, na qual tenho outro ID para criar meus objetos DDL.

Eu tenho tentado seguir um artigo de desenvolvimento do IBM chamado "Segurança do DB2, Parte 8: Doze melhores práticas de segurança do DB2" em minha tentativa de fazê-lo. Percebi que parece que o artigo foi escrito para o DB2 8.2 na época. Atualmente, estou trabalhando no DB2 9.7 fix pack 4 ESE para LUW. Especificamente, estou no AIX. No momento, estou testando como fazer isso em meu sistema local, que é o Windowx XP SP3 e usando o DB2 9.7 fix pack 4 Express-C para LUW.

Eu tenho minha conta de usuário local (que é o proprietário da instância) chamada db2admin neste caso (não em nossos sistemas AIX). Este ID pertence ao grupo DB2ADMNS. Como é diferente da minha conta do Windows, certifico-me de anexar à instância primeiro e, em seguida, criar meu banco de dados para garantir que db2admin seja concedido DBADM, SECADM, DATAACCESS, ACCESSCTRLem meu banco de dados.

db2 attach to DB2 user db2admin using ********
db2 create database SECTEST automatic storage yes on 'C:\' dbpath on 'C:\'
  using codeset UTF-8 territory US collate using system

Depois disso eu me conecto ao sistema como db2admin

db2 connect to sectest user db2admin using ********

Então, para testar as coisas, certifiquei-me de conceder CONNECTe SECADMà minha conta do Windows

db2 grant connect,secadm on database to user myid

E então eu queria configurar minha identidade falsa para criar objetos sob ela. Eu intencionalmente crio esse ID como nove caracteres para ajudar a impedir a conexão com o DB2 a partir da linha de comando, mas ainda o permito por meio de SET SESSION_USER. Para simplificar, chamei meu ID de bobabob97.

Então eu fiz o seguinte:

db2 grant CREATETAB,IMPLICIT_SCHEMA,BINDADD,CREATE_NOT_FENCED_ROUTINE,
  CREATE_EXTERNAL_ROUTINE on database to user bobabob97
db2 grant use of tablespace userspace1 to user bobabob97

Neste ponto, acho que tenho tudo configurado corretamente. Eu explicitamente não concedi bobabob97 CONNECTno banco de dados porque não quero que ninguém consiga se conectar ao banco de dados com este ID.

Portanto, agora tento mudar para esse ID para criar o teste de criação de meus objetos e possuí-los sob um ID genérico.

db2 set session_user=bobabob97

Mas então recebo o seguinte erro:

DB21034E O comando foi processado como uma instrução SQL porque não era um comando válido do Processador de Linha de Comandos. Durante o processamento SQL, retornou: SQL0552N "DB2ADMIN" não possui privilégio para executar a operação "SET SESSION AUTHORIZATION". SQLSTATE=28000

Então, agora estou intrigado. O ID que estou atualmente conectado ao banco de dados como (db2admin) tem DBADM, SECADM, DATAACCESS,e ACCESSCTRLno banco de dados (e é claro que contém implicitamente CONNECT, CREATETAB, BINDADD, QUIESCE_CONNECT, IMPLICIT_SCHEMA, LOAD, CREATE_NOT_FENCED_ROUTINE, e CREATE_EXTERNAL_ROUTINE). Eu sou essencialmente "deus" no banco de dados. Por que não posso mudar para este ID?

Tentei brincar com GRANT SETSESSIONUSER, mas sei SECADMque não pode conceder a si mesmo. O que eu faço aqui?

Esta questão começou porque tiramos cópias de backups de produção e as restauramos em ambientes inferiores (com dados embaralhados, é claro) para os desenvolvedores praticarem e/ou depurarem.

Temos IDs atribuídos DBADM, SECADM, DATAACCESSe ACCESSCTRL(principalmente o proprietário da instância). Quando restauramos para um ambiente inferior, acabamos precisando fazer logon como o proprietário da instância original e conceder as mesmas autoridades acima ( DBADM, SECADM, DATAACCESSe ACCESSCTRL) ao novo proprietário da instância de destino.

Achei que não era uma boa ideia deixar o ID original no banco de dados, então tentei revogar seus privilégios. Não muito tempo depois, minhas religações de pacotes começaram a falhar, pois aparentemente há pacotes vinculados a esse ID original. Sem saber o que eles continham e se eu poderia/deveria excluí-los ou não (mesmo pensando que eles são inofensivos para remover???) Acabei restaurando os privilégios para o proprietário da instância original e apenas deixando-o lá.

Isso sempre me incomodou. Um ID com os poderes de DBADM, SECADM, DATAACCESS, e ACCESSCTRLnão deveria estar apenas por aí. Para mim, isso é uma falha de segurança. Para mim, o ID deve ser revogado e qualquer outra limpeza que precise ser executada deve ser executada para manter o banco de dados seguro. O mesmo seria verdade se dissesse que eu deixaria a empresa ou meus colegas DBAs. Gostaríamos de revogar IDs e limpar e/ou transferir a propriedade de objetos para remover quaisquer brechas de segurança.

O problema é que não sei o que precisa ser limpo. Pesquisei um pouco na documentação do Google e da IBM e não encontrei nada que sugerisse as etapas que normalmente deveriam ser seguidas ao remover um usuário tão importante do sistema. Ou até mesmo um usuário com BINDADDautoridade?

O que todos vocês removem/revogam e em que ordem? Existe uma maneira de isso ser roteirizado/automatizado? Como você sabe quais pacotes você pode remover? Existem outras coisas que precisam ser movidas/transferidas?

Alguém mais encontra isso? Pensamentos? Experiências?

Estamos no processo de ajustar um aplicativo massivo que nossa empresa acabou de escrever. Parte desse ajuste inclui ajustar os bancos de dados. Executamos o DB2 LUW no AIX. Especificamente, estamos no Fix Pack 4 9.7 (embora esperemos migrar para o Fix Pack 2 10.1 ainda este ano).

Inicialmente, construímos tablespaces necessários apenas para o tamanho dos dados (ou seja, se todas as tabelas couberem em um tablespace 4K, criamos apenas tablespaces 4K, pensando por que criar tablespaces para ocupar mais disco se não forem usados). Isso foi o mesmo para tablespaces temporários também.

Os desenvolvedores nos disseram que obtiveram melhor desempenho adicionando um tablespace temporário de 32K. Portanto, todas as suas tabelas estão indo para tablespaces de 4K, 8K ou 16K. No entanto, eles adicionaram um temporário de 32K (que tem seu próprio bufferpool) e afirmam que reduziram pela metade alguns dos tempos de transação de seu aplicativo.

Quando penso nisso, suponho que faça sentido. Eu estou supondo que o otimizador vê o espaço de 32K como um ótimo lugar para realizar junções/classificações e tem mais memória à sua disposição sendo 32K vs 4K.

Meu colega disse que (independente do que foi dito acima) leu em algum lugar que os DBAs devem sempre colocar tablespaces temporários em seus próprios bufferpools. Quando pedi os links para ler, ele não conseguia se lembrar.

Estou pensando... os tablespaces temporários sempre devem ter seus próprios bufferpools? Isso ajuda no desempenho de junção/classificação? Isso é uma boa prática?

E, em segundo lugar, faz sentido sempre criar um bufferpool de 32K e espaços de tabela temporários de 32K para essas junções/classificações?

Sei que esta é uma questão um pouco mais subjetiva, mas estou procurando orientação da comunidade.

Nossa empresa é relativamente nova em ter DBAs. Costumávamos usar o DB2 para i nos servidores iSeries da IBM, então realmente não havia necessidade de um DBA (pelo menos operacionalmente), pois o sistema operacional praticamente gerenciava tudo para nós. Nos últimos anos, começamos a mudar para DB2 LUW no AIX. Assim nasceu a necessidade de DBAs. Três de nós estávamos interessados ​​em fazer a mudança de carreira de desenvolvedores para DBAs (dos quais eu sou um deles).

Como estamos no AIX, adotamos como padrão o uso de ksh como nossa linguagem de script para funções de gerenciamento de banco de dados (criação, implantação, operações, etc.). Eu descobri que o ksh é bastante poderoso, mas algumas das funções que preciso executar são bastante complexas. Um exemplo disso é minha pergunta sobre Unix e Linux StackExchange .

Com base nessa pergunta, assim como na leitura de blogs de outros administradores do DB2, vejo uma sugestão geral de que o Perl é mais adequado para scripts de administração do que o ksh.

Eu percebo que o fórum Unix/Linux teria seus próprios pensamentos sobre tal coisa, mas desejo abordar isso do ponto de vista da administração do banco de dados.

Independentemente do DBMS, qual linguagem de script parece mais adequada para administração na plataforma Unix/Linux? Perl? Ksh? (ou talvez outro?). Quais pontos fortes e fracos em seu uso de linguagens de script você encontrou como DBA e por que escolheu a linguagem que escolheu?

O que eu não quero é uma guerra altamente subjetiva sobre "Minha linguagem é melhor que a sua!" tipo de coisa, como eu costumava ver na comunidade de desenvolvimento sobre, digamos, Java vs Ruby, etc. Estou procurando informações honestas, tão objetivas quanto possível, sobre o que melhor atende às necessidades dos administradores de banco de dados.

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) |
+------------------------------+-----------------------+

Nossa empresa optou por usar o InfoSphere Data Architect (IDA) da IBM para a arquitetura de dados em relação ao nosso data warehouse e data marts.

Os arquitetos de dados projetaram originalmente várias tabelas "reutilizáveis" para nossos marts. Em outras palavras, uma tabela como CUSTOMER_DIMENSION pode residir estruturalmente em mais de um mart. Cada mart terá sua própria cópia de seus dados.

Acredito que para facilitar, eles definiram todas as tabelas (dimensões e fatos) dentro do mesmo "esquema" que chamaram de DB2ADMIN dentro do IDA.

Como um mart só pode ter uma tabela de fatos, tenho que examinar os diagramas dos relacionamentos das tabelas com as tabelas de fatos para determinar quais tabelas devem ser geradas em um arquivo DDL para um mart específico. A partir de agora, cada mart reside fisicamente em seu próprio esquema em um banco de dados. Portanto, não apenas tenho que escolher manualmente as tabelas para geração DDL, mas também ajustar manualmente cada arquivo DDL para substituir o esquema. Isso não é ideal, pois é um processo sujeito a erros.

Existe uma maneira de ter uma definição "base" de uma tabela e, em seguida, herdá-la ou qualquer outra coisa na tabela real no IDA? O que pretendo fazer é ter definições de esquema na ferramenta iguais às que temos em nosso servidor. Eu gostaria que apenas as tabelas aplicáveis ​​aparecessem dentro de cada esquema (como um mart deveria ser - um fato e apenas suas tabelas de dimensão com as quais ele se preocupa). Mas, para economizar trabalho, prefiro que as definições da tabela estejam em um só lugar. Assim, os arquitetos poderiam fazer uma alteração, mas poderíamos gerar nossas tabelas com mais facilidade.

Isso é possível? Há algum guru com IDA por aí?

Trabalhamos com DB2 LUW (especificamente estamos atualmente em 9.7 FP4) rodando em AIX.

De acordo com as melhores práticas da IBM, eles recomendam que, ao criar uma tabela, você coloque os dados, os índices e os dados LOBs/LONG cada um em seu próprio espaço de tabela. (A razão é melhor controle sobre o disco, manutenção, backups, etc.)

Tablespaces devem ser associados a bufferpools. No momento, a maioria de nossas tabelas e índices cabem em bufferpools e tablespaces de 4K.

Normalmente, com nossos scripts, configuramos um bufferpool 4K BP4K. Em seguida, configuramos pelo menos dois tablespaces de 4K (já que não temos muitos LOBs): TS_DAT_4K para dados e TS_IND_4K para índices. Por padrão, acabamos de atribuir esses espaços de tabela ao bufferpool BP4K.

O que eu me pergunto: como os índices estão em seu próprio espaço de tabela, eles também devem receber seu próprio bufferpool?

Minha razão para pensar isso é baseada na otimização. Se os índices tiverem seu próprio pool de buffers, é mais provável que eles permaneçam na memória (em vez de serem empurrados para fora da memória devido à leitura dos registros da tabela). Isso permitiria uma varredura mais rápida de índices para localizar os registros nas tabelas. E como os índices não compartilhariam mais o mesmo bufferpool com as tabelas, mais tabelas podem agora permanecer na memória para recuperação lógica em vez de uma leitura física. Então, meu pensamento é que isso reduziria a E/S física e, assim, ajudaria no desempenho/manutenção do banco de dados.

Também não posso deixar de me perguntar se isso é apenas pré-otimização, o que é 99% das vezes uma coisa ruim de se fazer, introduzindo sobrecarga extra etc. (especialmente porque não identificamos que precisamos de bufferpools separados ainda com base no desempenho atual. É claro que o aplicativo em desenvolvimento ainda não está em produção e ainda precisa de ajuste do banco de dados....)

Pensamentos sobre isso? Esta é uma prática recomendada? ou apenas pré-otimização e pensamento excessivo?

Estamos apenas começando a entrar em inteligência de negócios em nossa empresa. Temos alguns arquitetos que estão projetando nosso data warehouse e também nossos data marts. Eles estão usando o esquema em estrela para ambos os designs.

Os arquitetos afirmaram que o projeto que estão usando para os mercados é o mesmo, que só precisamos de "outra cópia" dele para qualquer cliente que deseje consultar seu mercado e que os dados podem diferir por mercado.

Nós só tínhamos um mercado para começar. Este foi um AIX LPAR, uma instância de banco de dados DB2 e um banco de dados, com um esquema.

Agora temos pedidos para mais três data marts. Qual é a melhor prática? Devem ser esquemas diferentes dentro do mesmo banco de dados? Cada mart deve ser um banco de dados separado dentro da mesma instância? Devemos ter bancos de dados separados, instâncias separadas?

Qual é a melhor prática aqui de uma perspectiva de implantação e manutenção física? Ou quais diretrizes são usadas para definir quando deve ser qual opção?

Acredito que entendo as razões por trás dos procedimentos armazenados protegidos e não protegidos.

Execução limitada "fora" do banco de dados (no nosso caso, DB2) para evitar possível corrupção do mecanismo do banco de dados, caso haja problemas com coisas como ponteiros.

Unfenced é executado "dentro" do banco de dados, o que significa que o desempenho é melhor.

Pelo que também pesquisei, o SQL PL sempre é basicamente não protegido, porque é SQL e, portanto, não pode acessar a memória como as linguagens de programação.

Os procedimentos C/C++ e Java podem ser executados com ou sem proteção. Mas, como eles podem acessar a memória, deve-se considerar executá-los protegidos, a menos que haja certeza da qualidade do código para não travar e que precise de desempenho.

Em primeiro lugar, estou correto em meu entendimento do que foi dito acima?

Em seguida, geralmente é uma prática recomendada começar com todos os procedimentos armazenados (mesmo aqueles definidos como SQL PL) como limitados primeiro?

Quaisquer outras práticas recomendadas para procedimentos armazenados, especialmente relacionados a cercas e/ou segurança?

EDIT: Pesquisas adicionais mostraram que os procedimentos SQL PL não podem ser executados com vedação. Como eles não contêm nenhum código que possa danificar o mecanismo do banco de dados, como ponteiros ou E/S de arquivo, o DB2 sabe que eles são seguros e os executa dentro do mecanismo (ou seja, sem proteção). Dito isto, ainda estou procurando as melhores práticas em relação a todos os outros procedimentos armazenados.

Eu me deparei com isso recentemente. Ao definir uma tabela no DB2 LUW (pelo menos 9,5 ou superior), você pode defini-la como NOT LOGGED INITIALLY.

Exemplo do livro que li:

CREATE TABLE products (
    productID      INT,
    product_Name   VARCHAR(30)
)
NOT LOGGED INITIALLY;

A documentação que li afirma que a tabela não é registrada durante a execução de INSERT, UPDATE, DELETE, CREATE INDEX, ALTER TABLEou DROP INDEXaté que uma COMMITinstrução seja executada. Tudo antes do COMMITnão é registrado. Tudo depois do COMMITé.

E, aparentemente, desde que você defina a tabela como NOT LOGGED INITIALLY, a qualquer momento você pode emitir um ALTER TABLE <table-name> ACTIVATE NOT LOGGED INITIALLYpara colocar a tabela de volta em um estado sem registro até que um COMMITseja emitido novamente.

Eles deram um exemplo que eu posso ver onde isso pode ser útil. O livro que li afirmou que você poderia emitir o seguinte

ALTER TABLE <table-name> ACTIVATE NOT LOGGED INITIALLY WITH EMPTY TABLE;

e isso aparentemente excluirá todos os dados da tabela sem registrá-los. Posso entender isso como desejável em um ambiente de teste em que você deseja limpar os dados e testar novamente sem a sobrecarga de desempenho de registrar a exclusão para reversão.

Mas além deste caso, estou intrigado. Existe algum motivo para você não querer fazer logon em uma tabela fora de um ambiente de teste? Que outras utilizações existem para este tipo de mesa?

Recentemente, passei de desenvolvedor Java para um DBA real em nossa empresa. Estou aprendendo as regras, por assim dizer, sobre ser um DBA (que na verdade é uma nova posição para nossa empresa).

Já vi vários scripts onde executamos o comando DB2 BIND bind_file other_parameters.

Estou intrigado com o que estes fazem. Perguntei aos nossos outros DBAs, mas eles não conseguiram me explicar de uma maneira que fizesse sentido. Eu olhei para o Centro de Informações da IBM para o comando BIND , mas também não estava claro para mim.

Eu sei que a vinculação é de alguma forma importante, porque devemos executar REORGS, executar STATS e re-BIND em nossos bancos de dados regularmente para ajudar no desempenho.

Como ainda sou um DBA n00b, gostaria de saber se alguém pode fornecer um "O que é BINDing for Dummies?" explicação?

EDIT : Na edição da resposta abaixo, recentemente me deparei com o seguinte artigo do developerworks: "Pacotes DB2: Conceitos, exemplos e problemas comuns: Entendendo os pacotes do sistema DB2 e do aplicativo do usuário" . Muito útil. Especialmente para os pacotes do sistema, que é o que mais nos deparamos.

20130905 EDIT : Esta entrada de blog do DB2 DBA Ember Crooks é excelente no que diz respeito à vinculação e ao que isso significa. Ela também escreveu uma entrada anterior sobre pacotes não encontrados e quando aumentar o número CLIPKG para as ligações e o que isso significa. Esses artigos estão muito bem explicados. Basicamente como ler "DB2 Binding and Packages for Dummies" se tal coisa existisse.

Isso é para o DB2 9.7 Enterprise Server Edition no AIX.

Fiz um backup offline completo de vários bancos de dados em nossa instância em um ambiente de desempenho.

Eu queria restaurar esses bancos de dados para nosso ambiente de integração.

eu executei o comando

db2 restore database database_name from 
/bkp/instance_name/OfflineBackups/RestorePoint/my_restore_point 
taken at 20120321103846 into database_name without prompting;

para cada um dos meus bancos de dados (modificando o nome do banco de dados e o carimbo de data/hora adequadamente, é claro).

Cada banco de dados foi restaurado com sucesso de acordo com o DB2. No entanto, agora quando desejo verificar se o banco de dados realmente restaurou o que eu pensava, tento me conectar a um banco de dados e recebo o erro

    SQL1117N  A connection to or activation of database "database_name" cannot be made 
because of ROLL-FORWARD PENDING.  SQLSTATE=57019

Eu não tinha nenhuma transação em processo no banco de dados anterior porque todas as conexões foram forçadas e o banco de dados estava inativo para um backup offline. O que eu faço?

Nossa loja de TI está começando a construir um grupo de DBA's. Todos nós (inclusive eu) viemos do mundo do desenvolvimento de aplicativos/arquitetura, então o mundo DBA ainda é relativamente novo para nós.

Juntamente com a construção de um grupo de DBA, estamos procurando criar procedimentos e processos de gerenciamento de mudanças (esperançosamente baseados nas melhores práticas) para quando precisarmos mover mudanças.

Encontrei a postagem a seguir que é útil principalmente para alterações de gatilho, procedimento armazenado e/ou DDL. Mas não aborda necessariamente índices ou bancos de dados de fornecedores.

Temos uma mistura de bancos de dados próprios e de fornecedores. Em nosso caso, alguns dos fornecedores (embora não todos) estão trabalhando com nossa empresa para construir o(s) banco(s) de dados e aplicativos. Estamos no processo de teste de desempenho de nossos aplicativos agora, antes que eles "entrem no ar". Assim, estamos analisando os índices (ou a falta deles) bastante.

À medida que nos deparamos com índices que achamos que deveriam ser feitos, como lidamos melhor com o gerenciamento de mudanças em relação a eles, tanto para nossos próprios bancos de dados quanto para quaisquer fornecedores?

O que você faz na sua loja? Estou menos preocupado com as ferramentas do que com o processo.

EDIT: Até agora, estou apreciando o feedback, comentários e respostas para esta pergunta. Percebi que algumas das respostas são um pouco específicas da ferramenta. Estou procurando práticas mais "agnósticas", se possível.

No entanto, se o agnóstico não for possível, para conjuntos de ferramentas, usamos principalmente o IBM DB2 LUW (e, na verdade, no AIX). Temos algum DB2 no Windows e DB2 para i (IBM's i5/OS), mas somos principalmente AIX DB2. Nós usamos o controle de origem, especificamente o Subversion.

Novamente, procurando as melhores práticas gerais, mas acima está o que usamos que seria específico do fornecedor.

EDIT: Decisão atual: Pretendemos acompanhar nosso raciocínio, bem como nossas mudanças. Então, vamos abrir um problema em nosso software de rastreamento de problemas (que no nosso caso é o JIRA). Agora podemos adicionar documentação sobre a prioridade da mudança, dados que respaldam qual deve ser a mudança, a mudança e os resultados da mudança de outro ambiente onde a mudança foi testada.

Também pretendemos acompanhar nossas alterações nos scripts no SVN (como foi sugerido abaixo). Dessa forma, podemos rastrear qual versão do que existe onde. Isso pode ser registrado em nosso problema do JIRA (e em qualquer outro software de auditoria que usamos, ou seja, links colados). Podemos saber com mais certeza que mudança ocorreu em qual ambiente e por quê. Também podemos rastrear se o índice foi algo que adicionamos além da implementação dos fornecedores ou antes de sua implementação, etc.)

Instalamos (recentemente) o Cognos 10 da IBM como nossa ferramenta de relatório de inteligência de negócios. A maioria dos bancos de dados que relatamos são DB2 9.7 LUW Enterprise Edition. Instalamos o DB2 Runtime-Time Client para que o Cognos tenha acesso ao driver para se comunicar com o DB2.

Também temos alguns sistemas legados e bancos de dados em nosso iSeries (também conhecido como AS/400) - então isso significa DB2 para i. Precisamos que o Cognos agora reconheça esses bancos de dados. Pelo que lemos, precisamos instalar o DB2Connect para conceder acesso ao DB2 for i de uma perspectiva DB2 LUW.

Nosso Cognos foi instalado em um sistema Windows Server. Instalamos o RTC no mesmo sistema e podemos catalogar bancos de dados DB2 LUW. Podemos fazer com que o Cognos crie origens de dados com esses bancos de dados.

Para obter a funcionalidade do iSeries, instalamos recentemente o DB2Connect (no mesmo sistema que o Cognos e o RTC) e conseguimos catalogar o banco de dados do iSeries, conectá-lo e chamá-lo. Mas não podemos fazer o Cognos ver o banco de dados catalogado. Parece que não está lá.

Parte da documentação que examinamos faz parecer que você não pode acessar dois drivers DB2 diferentes localmente no mesmo processo no Cognos.

Nossos pensamentos:

1. Desinstale o RTC e apenas instale o DB2Connect com todas as fontes de dados catalogadas por meio dele e, em seguida, faça com que o Cognos as procure. Nossa preocupação com esse método é que temos medo de que o Cognos perca informações de relatórios existentes e projetos já configurados. Não queremos atrapalhar/perder o trabalho já feito por outras equipes.
2. Estamos nos perguntando se haveria uma maneira limpa e agradável de migrar do RTC para o DB2Connect para que pudéssemos mover as conexões de um para o outro. Nossa preocupação aqui... como podemos fazer com que o DB2Connect seja reconhecido pela Cognos em primeiro lugar?
3. Existe outra maneira de catalogar os bancos de dados do iSeries e/ou fazer com que sejam reconhecidos pelo Cognos?

Pensamentos? Ideias?

Edit: Nossa empresa decidiu não esperar. Eles estão trazendo um consultor para nos ajudar a reconstruir isso do zero, para entendermos melhor o produto, como ele é instalado, funciona etc.

Dito isto, eu ainda gostaria de receber quaisquer pensamentos ou ideias sobre este.

Eu tenho como minha estação de desenvolvedor um laptop com SO Windows XP Professional Edition, Service Pack 3.

Fiz download e instalei o IBM DB2 UDB 9.7 fix pack 4, da edição Express-C.

Eu tenho uma conta local do Windows chamada db2admin que estou usando como meu administrador de banco de dados local para minha instalação local do DB2 (somente para fins de desenvolvedor).

Posso executar o seguinte sem problemas ao executar a janela de comando:

db2 attach to db2 user db2admin using xxxxxxxxxx

Isso me permite anexar à minha instância chamada DB2.

Eu posso executar meus comandos de criação de banco de dados.

Em seguida, tento me conectar ao banco de dados para conceder todos os privilégios para minha conta db2admin no DB2.

db2 CONNECT TO MYDB;
SET SCHEMA DB2ADMIN;
db2 GRANT DBADM,CREATETAB,BINDADD,CONNECT,CREATE_NOT_FENCED_ROUTINE,IMPLICIT_SCHEMA,LOAD,CREATE_EXTERNAL_ROUTINE,QUIESCE_CONNECT,SECADM ON DATABASE TO USER DB2ADMIN;
CONNECT RESET;

No entanto, quando executo isso, o DB2 me informa que minha conta de usuário real do Windows (synprgcma) não tem autoridade para conceder autoridade ao usuário db2admin.

Então, se eu alterar o segundo script para o seguinte:

db2 CONNECT TO MYDB USER db2admin USING xxxxxxxx;
SET SCHEMA DB2ADMIN;
db2 GRANT DBADM,CREATETAB,BINDADD,CONNECT,CREATE_NOT_FENCED_ROUTINE,IMPLICIT_SCHEMA,LOAD,CREATE_EXTERNAL_ROUTINE,QUIESCE_CONNECT,SECADM ON DATABASE TO USER DB2ADMIN;
CONNECT RESET;

Então o DB2 me diz que db2admin não pode revogar ou conceder autoridade a si mesmo (na verdade, ele me diz que um id não pode revogar ou conceder autoridade a si mesmo).

Então estou perplexo. Eu não tive esse problema com minha instalação anterior do DB2 (9.5, e não me lembro em qual fix pack eu estava).

Como eu concedo as autoridades necessárias para a conta de administrador local? Acredito que preciso disso para executar um comando de ligação que preciso fazer a seguir:

db2 CONNECT TO MYDB;
db2 bind @db2cli.lst blocking all grant public sqlerror continue CLIPKG 20;
db2 CONNECT RESET;

Qualquer ajuda seria apreciada.

Edit: Encontrei alguns dos seguintes links relacionados a isso. Ainda não tenho certeza de como fazê-lo funcionar, mas pelo menos encontrei alguma documentação.

• http://www.db2teamblog.com/2009/06/whats-new-in-db2-97.html
• http://lpetr.org/blog/archives/simplify-the-db2-9-7-security-model
• http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.sql.ref.doc%2Fdoc%2Fr0000958.html
• http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14288459
• http://publib.boulder.ibm.com/infocenter/tivihelp/v4r1/index.jsp?topic=%2Fcom.ibm.tpc_V422.doc%2Ffqz0_t_preparing_to_install_db2_windows.html
• http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.sec.doc%2Fdoc%2Fc0055206.html
• http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.sec.doc%2Fdoc%2Fc0005479.html