Início / dba / Perguntas / 16585
Accepted
Chris Aldrich
Asked: 2012-04-17 11:30:18 +0800 CST

O que exatamente é vinculativo no DB2?

  • 772

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.

db2

1 respostas

  1. Best Answer

    Vejo que o link do seu Centro de Informações vai para o LUW 9.7 e você menciona que programou em Java, mas a maior parte da experiência que tenho com vinculação é com DB2 no Mainframe com COBOL. Portanto, talvez seja necessário adaptar um pouco a explicação (mas geralmente os conceitos devem ser os mesmos).

    Acredito que a vinculação seja relevante apenas quando você estiver compilando programas que incluem SQL incorporado que é pré-compilado (SQL vinculado estaticamente). Se, por exemplo, você estiver usando JDBC, não será necessário executar um BIND. O driver JDBC fará PREPAREa instrução dinamicamente.

    Quando você executa um programa por meio de um pré-compilador do DB2, PRECOMPILEexecuta seu programa e encontra qualquer SQL incorporado (em COBOL, esses são blocos de instrução que vão de EXEC SQLpara END-EXEC.), ele extrai cuidadosamente o SQL e o substitui por um chamada para a interface COBOL-DB2. Depois disso, há duas saídas do PRECOMPILE, a fonte COBOL que teve todo o SQL embutido removido ( Aa partir de agora), e uma DBRMque contém todo o SQL que foi removido ( B).

    A pré-compilação faz algumas verificações básicas de sintaxe, mas esteja ciente de que as verificações são baseadas apenas em suas declarações de tabela dentro do programa. Ele não se conecta ao DB2 para verificar isso!

    Esses dois arquivos são completamente separados e, quando você executa o programa COBOL, ele precisa localizar um Ae um Bque foram gerados ao mesmo tempo.

    Neste ponto, Aé compilado e vinculado ao compilador COBOL padrão em um load modulee colocado em uma biblioteca de carregamento para ser usado posteriormente.

    No entanto, ainda há muito trabalho a ser feito com Bo DBRM. É aqui que BINDentra. BINDé como um compilador para o código SQL embutido, e a saída da "compilação" é um arquivo package.

    Para BIND o SQL em um "pacote" executável, o processo BIND é anexado ao DB2 e faz algumas coisas:

    • Verifica se o AuthID atual está autorizado a realizar uma ligação.
    • Verifica a sintaxe de seu SQL, com ajuda dos dados no catálogo do DB2.
    • Finalmente, e mais importante, o bind otimizará seu SQL

    Durante a última etapa, todo o seu SQL é executado por meio do Optimizer, que leva em consideração todas as estatísticas e vários caminhos que o mecanismo do DB2 pode seguir para buscar seus dados. Em seguida, ele escolhe o caminho que surgiu com o menor custo associado (com versões mais recentes do DB2 [DB2 10 para z/OS] , ele pode optar por um caminho de "custo mais alto", mas de "risco mais baixo"). Depois que o caminho é selecionado, ele é compilado e se torna um pacote, que é armazenado no catálogo (você pode ver todos os seus pacotes atuais com SELECT * FROM SYSIBM.SYSPACKAGE(z/OS)).

    Finalmente, há uma última peça que permite que nossos programas se reúnam com seus pacotes, o PLAN. Você cria um plano fazendo outro BIND ( BIND PLAN). Um plano é uma coleção de pacotes que o programa pode examinar para encontrar o pacote que compartilha o mesmo nome. Com COBOL, você especifica em qual plano o programa deve pesquisar em seu JCL.

    Em resumo, o código compilado passa por estas etapas para gerar um arquivo BIND PLAN:

    Pré-compilar -> Cria um DBRM (com C[++], o pré-compilador envia o SQL pré-compilado para um arquivo HFS, que pode ser enviado através do programa de ligação de linha de comando ) -> o DBRM é otimizado e um conjunto de caminhos de acesso ( a package) é criado -> O pacote é adicionado a um BIND PLAN, que é um grupo de pacotes que permite que você crie um "caminho de pesquisa" para seus programas procurarem.

    Como esses programas são vinculados estaticamente, se as estatísticas da sua tabela mudarem drasticamente, o caminho de acesso que o otimizador escolheu no momento da ligação pode não ser mais o melhor caminho, e a religação permitirá reavaliar o SQL e talvez escolher um melhor caminho.

    Editar (atualização para comentário): Se você estiver usando o processador de linha de comando, poderá passar um único pacote de ligação (.bnd) ou uma lista de nomes de arquivos de ligação (.lst). Se você passar uma lista, o nome do arquivo deve ser precedido por um@(por exemplo/path/to/@packages.lst, ). Dentro do arquivo .lst, você pode colocar cada pacote em uma linha individual ou separá-los com+:

    package1.bnd
package2.bnd
package3.bnd+package4.bnd+package5.bnd
    • 3

relate perguntas