O que exatamente está vinculando no DB2?

8

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

Eu vi vários scripts em que executamos o comando DB2 BIND bind_file other_parameters.

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

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

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

EDIT : Na edição da resposta abaixo, deparei-me recentemente com o seguinte artigo do developerWorks: "Pacotes do DB2: conceitos, exemplos e problemas comuns: Entendendo os pacotes do sistema DB2 e de aplicativos do usuário" . Muito útil. Especialmente para os pacotes de sistema, que é o que mais encontramos.


20130905 EDIT : Esta entrada de blog do DB2 DBA Ember Crooks é excelente em relação à ligaçã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. Estes artigos são muito bem explicados. Basicamente, como ler "Ligação e pacotes do DB2 para manequins", se isso existir.

Chris Aldrich
fonte
11
Muito obrigado pelos indicadores em suas edições de acompanhamento @ Chris!
Rob Wells

Respostas:

3

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

Eu acredito que a ligação só é relevante quando você está compilando programas que incluem SQL incorporado que é pré-compilado (SQL vinculado estaticamente). Se, por exemplo, você estiver usando JDBC, não precisará executar um BIND. O driver JDBC fará PREPAREa declaração dinamicamente.


Quando você executar um programa através de um DB2 pré-compilador, PRECOMPILEexecutado através de seu programa, e se encontra qualquer SQL embutido (em COBOL, estes são blocos de instrução que vão desde EXEC SQLa END-EXEC.), ele rasga cuidadosamente o SQL, e substitui-lo com um ligue para a interface COBOL-DB2. Depois disso, há duas saídas da PRECOMPILEfonte COBOL que teve todo o SQL incorporado removido (a Apartir de agora) e um DBRMque contém todo o SQL removido ( B).

O pré-compilado faz algumas verificações básicas de sintaxe, mas lembre-se de que as verificações são baseadas apenas nas declarações da sua tabela no programa. Não é anexado ao DB2 para verificar isso!

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

Nesse ponto, ele 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 B, o DBRM. É aqui que BINDentra. BINDÉ como um compilador para o código SQL incorporado, e a saída da "compilação" é a 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 executar uma ligação.
  • Verifica a sintaxe do seu SQL, com ajuda dos dados no catálogo do DB2.
  • Finalmente, e mais importante, a ligação otimizará seu SQL

Durante a última etapa, todo o seu SQL é executado através 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, escolhe o caminho que apresentou com o menor custo associado (nas versões mais recentes do DB2 [DB2 10 para z / OS] , pode-se optar por um caminho de "custo mais alto", mas com "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 executando outro BIND ( BIND PLAN). Um plano é uma coleção de pacotes que o programa pode procurar para encontrar o pacote que compartilha o mesmo nome. Com COBOL, você especifica em qual plano o programa deve procurar em sua JCL.


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

Pré-compilar -> Cria um DBRM (com C [++], o pré-compilador gera o SQL pré-compilado em um arquivo HFS, que pode ser enviado por meio do programa de ligação da linha de comando ) -> o DBRM é otimizado e um conjunto de caminhos de acesso ( a package) é criado -> O pacote é adicionado a a BIND PLAN, que é um grupo de pacotes que permite criar um "caminho de pesquisa" para os seus programas examinarem.

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


Editar (atualizar para comentar): 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 em uma lista, o nome do arquivo deve ser anexado com 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
bhamby
fonte
Se assim posso acrescentar à minha pergunta e, portanto, à sua resposta ... qual é a diferença entre arquivos .lst e .bnd para vinculação? Notei que ligamos alguns arquivos .lst (geralmente DB2 BIND @ myFile.lst ....) e arquivos .bnd (o mesmo, mas sem o sinal @). Você poderia adicioná-los à sua resposta também?
31812 Chris Aldrich
11
@ ChrisAldrich: a resposta foi atualizada. Basicamente, .bnds são os arquivos de ligação e .lsts são listas de arquivos de ligação.
bhamby
outra pergunta. Acho que isso ainda me intriga ... Os arquivos .bnd e .lst aos quais estamos vinculando são arquivos que a IBM forneceu com o DB2 e não nada personalizado para o qual escrevemos. Então ... acho que ainda estou confuso sobre o que exatamente está vinculando ao quê. Como a IBM sabe o que temos? ou vice-versa? O que a execução de ligações com esses arquivos faz exatamente? Espero que isso não frustre. Como eu disse, realmente procurando uma resposta no estilo "para manequins", porque ainda é confusa para mim.
31812 Chris Aldrich
11
Desculpe por isso, você me pegou logo antes de sair de férias! Enfim, para responder sua pergunta, o que eu acho que você é vinculativo é db2ubind.lste / ou db2cli.lst. Esses arquivos são criados automaticamente quando um novo banco de dados é criado no servidor e permitem que vários utilitários de clientes remotos funcionem (suporte a CLI / ODBC; DB2 CLP; utilitários de importação / exportação). Confira este link
bhamby: