Che cosa è esattamente vincolante in DB2?

Di recente sono passato dall'essere uno sviluppatore Java a un vero DBA nella nostra azienda. Sto imparando le corde, per così dire, sull'essere un DBA (che in realtà è in qualche modo una nuova posizione per la nostra azienda).

Ho visto diversi script in cui eseguiamo il comando DB2 BIND bind_file other_parameters.

Sono perplesso da ciò che fanno. Ho chiesto agli altri DBA, ma non sono stati in grado di spiegarmelo in un modo sensato. Ho esaminato il centro informazioni di IBM per il comando BIND , ma non era chiaro neanche a me.

So che l'associazione è in qualche modo importante, perché dovremmo eseguire REORGS, eseguire STATS e re BIND sui nostri database regolarmente per assistere con le prestazioni.

Dato che sono ancora un DBA n00b, mi chiedevo se qualcuno potesse fornire un "Cos'è BINDING for Dummies?" spiegazione?

EDIT : In edizione alla risposta di seguito, di recente mi sono imbattuto nel seguente articolo di Developerworks: "Pacchetti DB2: concetti, esempi e problemi comuni: comprensione del sistema DB2 e dei pacchetti dell'applicazione utente" . Molto utile. Soprattutto per i pacchetti di sistema, che è quello in cui ci siamo imbattuti principalmente.

20130905 EDIT : questo post sul blog di DB2 DBA Ember Crooks è stellare per quanto riguarda il legame e il suo significato. Ha anche scritto una voce precedente sui pacchetti che non sono stati trovati e su quando aumentare il numero CLIPKG per i bind e cosa significa. Questi articoli sono molto ben spiegati. Fondamentalmente mi piace leggere "DB2 Binding and Packages for Dummies" se esistesse una cosa del genere.

Vedo che il tuo link al Centro informazioni va a LUW 9.7 e dici che hai programmato in Java, ma la maggior parte dell'esperienza che ho con l'associazione è con DB2 sul mainframe con COBOL. Quindi, potrebbe essere necessario adattare un po 'la spiegazione (ma in generale, i concetti dovrebbero essere gli stessi).

Credo che l'associazione sia pertinente solo quando si compilano programmi che includono SQL incorporato precompilato (SQL associato staticamente). Se, ad esempio, stai utilizzando JDBC, non è necessario eseguire un BIND. Il driver JDBC eseguirà PREPAREla dichiarazione in modo dinamico.

Quando si esegue un programma tramite un pre-compilatore DB2, si PRECOMPILEesegue il programma e, se trova qualsiasi SQL incorporato (in COBOL, si tratta di blocchi di istruzioni che vanno da EXEC SQLa END-EXEC.), strappa con attenzione l'SQL e lo sostituisce con un chiama all'interfaccia COBOL-DB2. Successivamente, ci sono due output di PRECOMPILE, l'origine COBOL a cui è stato rimosso tutto l'SQL incorporato ( Ad'ora in poi) e uno DBRMche contiene tutto l'SQL che è stato rimosso ( B).

Precompile esegue alcuni controlli di sintassi di base, ma tieni presente che i controlli si basano solo sulle dichiarazioni delle tabelle all'interno del programma. Non si collega a DB2 per verificarli!

Questi due file sono completamente separati e quando si esegue il programma COBOL, deve trovare un Ae un Bgenerato allo stesso tempo.

A questo punto, Aviene compilato e collegato con il compilatore COBOL standard in un load modulee inserito in una libreria di caricamento da utilizzare in seguito.

Tuttavia, c'è ancora molto lavoro da fare B, il DBRM. È qui che BINDentra in gioco. BINDÈ un po 'come un compilatore per il codice SQL incorporato e l'output della "compilazione" è a package.

Al fine di BIND l'SQL in un "pacchetto" eseguibile, il processo BIND si collega a DB2 e fa alcune cose:

• Verifica che l'attuale AuthID sia autorizzato a eseguire un bind.
• Verifica la sintassi del tuo SQL, con l'aiuto dei dati nel catalogo DB2.
• Infine, e soprattutto, il bind ottimizzerà il tuo SQL

Durante l'ultimo passaggio, tutto il tuo SQL viene eseguito tramite lo Strumento per ottimizzare, che tiene conto di tutte le statistiche e dei vari percorsi che il motore DB2 potrebbe prendere per recuperare i tuoi dati. Quindi sceglie il percorso che ha trovato con il costo più basso associato (con le versioni più recenti di DB2 [DB2 10 per z / OS] , può decidere di prendere un percorso "costo più elevato", ma "rischio più basso"). Una volta selezionato il percorso, viene compilato e diventa un pacchetto, che viene memorizzato nel catalogo (è possibile visualizzare tutti i pacchetti correnti con SELECT * FROM SYSIBM.SYSPACKAGE(z / OS)).

Infine, c'è un ultimo pezzo che consente ai nostri programmi di riunirsi con i loro pacchetti, il PLAN. Si crea un piano facendo un altro BIND ( BIND PLAN). Un piano è una raccolta di pacchetti che il programma può esaminare per trovare il pacchetto che condivide lo stesso nome. Con COBOL, specifichi in quale piano deve cercare il programma nel tuo JCL.

In breve, il codice compilato esegue questi passaggi per generare un utilizzabile BIND PLAN:

Precompila -> Crea un DBRM (con C [++], il precompilatore genera l'SQL precompilato in un file HFS, che può essere inviato tramite il programma di bind della riga di comando ) -> il DBRM è ottimizzato e un insieme di percorsi di accesso ( a package) viene creato -> Il pacchetto viene aggiunto a BIND PLAN, ovvero un gruppo di pacchetti che consente di creare un "percorso di ricerca" per consentire ai programmi di scorrere.

Poiché questi programmi sono associati staticamente, se le statistiche della tabella cambiano drasticamente, il percorso di accesso scelto dall'ottimizzatore al momento del bind-time potrebbe non essere più il percorso migliore e il ri-binding consentirà di rivalutare l'SQL e forse scegliere un percorso migliore.

Modifica (aggiorna per commento): se si utilizza il processore della riga di comando, è possibile passare un singolo pacchetto bind (.bnd) o un elenco di nomi file bind (.lst). Se si passa in un elenco, il nome file deve essere anteposto con un@(ad es/path/to/@packages.lst.). All'interno del file .lst, è possibile inserire ciascun pacchetto su una singola riga oppure separarli con+:

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