O que exatamente está vinculando no DB2?

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.

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