it-swarm-eu.dev

Co přesně je vázání v produktu DB2?

Nedávno jsem přešel z toho, že jsem vývojářem Java) na skutečný DBA v naší společnosti. Učím se lana, abych tak řekl, o tom, že jsem DBA (což je vlastně poněkud nová pozice pro naše společnost).

Viděl jsem několik skriptů, kde spustíme příkaz DB2 BIND bind_file other_parameters.

Jsem zmatený tím, co dělají. Požádal jsem naše další DBA, ale oni mi to nemohli vysvětlit tak, aby to dávalo smysl. Podíval jsem se na Informační centrum IBM pro příkaz BIND , ale nebylo mi to jasné.

Vím, že vazba je nějak důležitá, protože jsme měli v našich databázích pravidelně spouštět REORGS, STATUT a BIND, abychom jim pomohli s výkonem.

Vzhledem k tomu, že jsem stále n00b DBA, přemýšlel jsem, jestli může někdo poskytnout „Co je BINDing pro Dummies?“ vysvětlení?

[~ # ~] editovat [~ # ~] : V edici k odpovědi níže jsem nedávno narazil na následující článek pro vývojáře: "Balíčky DB2: Koncepty, příklady a běžné problémy: Porozumění balíčkům systémových a uživatelských aplikací DB2" . Velmi nápomocný. Zejména pro systémové balíčky, do kterých jsme většinou narazili.


20130905 EDIT : Tento položka blog od DB2 DBA Ember Crooks je hvězdný s ohledem na vázání a co to znamená. Také napsala předchozí položka na balíčcích nebyla nalezena a kdy zvýšit číslo CLIPKG pro vazby a co to znamená. Tyto články jsou velmi dobře vysvětleny. DB2 Binding and Packages for Dummies “, pokud taková věc existovala.

8
Chris Aldrich

Vidím, že váš odkaz na Informační centrum přejde na LUW 9.7 a zmiňujete, že jste programovali v Javě, ale většina zkušeností, které mám s vazbou, je s DB2 na Mainframe s COBOLem. Možná budete muset trochu upravit vysvětlení (ale obecně by koncepty měly být stejné).

Věřím, že vazba je relevantní pouze při kompilaci programů, které obsahují vložený SQL, který je předkompilován (staticky vázaný SQL). Pokud například používáte JDBC, nemusíte spouštět BIND. Ovladač JDBC bude PREPARE příkaz dynamicky.


Když spustíte program pomocí předkompilátoru DB2, PRECOMPILE spustí váš program a pokud najde nějaký vložený SQL (v COBOLu, jedná se o bloky příkazů, které vycházejí z EXEC SQL to END-EXEC.), pečlivě vytrhne SQL a nahradí jej voláním rozhraní COBOL-DB2. Poté jsou k dispozici dva výstupy zdroje PRECOMPILE, COBOL, ve kterém byly odstraněny všechny vložené SQL (od této chvíle A) a DBRM, který obsahuje všechny SQL, který byl odstraněn (B).

Předkompilace provádí některé základní kontroly syntaxe, ale mějte na paměti, že kontroly jsou založeny pouze na deklaracích tabulky v programu. Nepřipojuje se k produktu DB2, aby je ověřil!

Tyto dva soubory jsou zcela oddělené a při spuštění programu COBOL musí najít A a B, které byly vygenerovány současně.

V tomto okamžiku je A kompilován a propojen se standardním kompilátorem COBOL do load module a umístěny do knihovny zatížení pro pozdější použití.

S B, DBRM, však stále zbývá mnoho práce. Zde přichází BIND. BIND je něco jako kompilátor pro vložený kód SQL a výstupem "compile" je package.

Za účelem BIND SQL do spustitelného „balíčku“ se proces BIND připojí k DB2 a provede několik věcí:

  • Ověří, že aktuální AuthID je oprávněn provést vazbu.
  • Zkontroluje syntaxi vašeho SQL s pomocí dat v katalogu DB2.
  • A co je nejdůležitější, vazba optimalizuje váš SQL

V posledním kroku je veškerá vaše SQL spuštěna pomocí Optimalizátoru, který bere v úvahu všechny statistiky a různé cesty, které může stroj DB2 použít k načtení vašich dat. Poté vybere cestu, se kterou přišel, která má nejnižší náklady spojené (s novějšími verzemi DB2 [DB2 10 pro z/OS] , může se rozhodnout vzít „vyšší cenu“, ale „ cesta s nižším rizikem). Jakmile je cesta vybrána, zkompiluje se a stane se balíčkem, který je uložen v katalogu (všechny vaše aktuální balíčky můžete zobrazit pomocí SELECT * FROM SYSIBM.SYSPACKAGE (z/OS)).

Konečně je tu poslední kousek, který umožňuje našim programům opětovné spojení s jejich balíčky, PLAN. Plán vytvoříte provedením jiného BIND ( BIND PLAN ). Plán je kolekce balíčků, které si program může prohlédnout, aby našel balíček, který sdílí stejný název. Pomocí COBOLu určíte, ve kterém plánu by měl program prohledávat ve vašem JCL.


Zkrátka, zkompilovaný kód prochází těmito kroky, aby vytvořil použitelný BIND PLAN:

Předkompilace -> Vytvoří DBRM (s C [++], předkompilátor vydá předkompilovanou SQL do souboru HFS, který lze odeslat prostřednictvím příkazového řádku vazebného program ) -> DBRM je optimalizován a vytvoří se sada přístupových cest (package) -> Balíček se přidá do BIND PLAN, což je skupina balíčků, které vám umožňují vytvořit "vyhledávací cestu", kterou si programy mohou prohlédnout.

Protože tyto programy jsou staticky vázané, pokud se statistika vaší tabulky drasticky změní, pak přístupová cesta, kterou optimalizátor zvolil v době vazby, už možná nebude nejlepší cestou, a opětovné navázání jí umožní přehodnotit SQL a možná zvolit lepší cesta.


Upravit (aktualizace pro komentář): Pokud používáte procesor příkazového řádku, můžete předat buď jeden vážit balíček (.bnd) nebo seznam názvů svázaných souborů (.lst). Pokud předáte seznam, musí být název souboru doplněn znakem @ (např. /path/to/@packages.lst). Uvnitř souboru .lst můžete buď umístit každý balíček na samostatný řádek, nebo je můžete oddělit pomocí +:

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