Что именно является обязательным в DB2?

Недавно я перешел от Java-разработчика к настоящему администратору в нашей компании. Я, так сказать, изучаю веревки, чтобы быть администратором баз данных (что на самом деле является новой позицией для нашей компании).

Я видел несколько сценариев, где мы запускаем команду DB2 BIND bind_file other_parameters.

Я озадачен тем, что они делают. Я спросил у других наших администраторов баз данных, но они не смогли объяснить это мне так, чтобы это имело смысл. Я заглянул в Информационный центр IBM за командой BIND , но мне это тоже было непонятно.

Я знаю, что связывание как-то важно, потому что мы должны регулярно запускать REORGS, STATS и повторно BIND для наших баз данных, чтобы повысить производительность.

Так как я все еще являюсь администратором базы данных n00b, мне было интересно, кто-нибудь может предоставить «Что такое BINDing для чайников?» объяснение?

РЕДАКТИРОВАТЬ : В редакции к ответу ниже, я недавно наткнулся на следующую статью developerWorks: «Пакеты DB2: концепции, примеры и типичные проблемы: понимание системы DB2 и пакетов пользовательских приложений» . Очень полезно. Особенно для системных пакетов, с которыми мы чаще всего сталкивались.

20130905 РЕДАКТИРОВАТЬ : Эта запись в блоге DB2 DBA Ember Crooks является звездным с точки зрения связывания и что это значит. Она также написала предыдущую запись о пакетах, которые не были найдены и о том, когда нужно увеличить номер CLIPKG для привязок и что это значит. Эти статьи очень хорошо объяснены. В основном, как чтение «Связывание DB2 и пакеты для чайников», если такая вещь существовала.

Я вижу, что ваша ссылка на информационный центр ведет к LUW 9.7, и вы упоминаете, что вы программировали на Java, но большая часть опыта, с которым я связывался, связана с DB2 на мейнфрейме с COBOL. Таким образом, вам может понадобиться немного адаптировать объяснение (но, как правило, концепции должны быть одинаковыми).

Я считаю, что связывание имеет значение только тогда, когда вы компилируете программы, которые включают встроенный SQL, который является предварительно скомпилированным (статически связанный SQL). Если, например, вы используете JDBC, вам не нужно запускать BIND. Драйвер JDBC будет PREPAREдинамически утверждать оператор.

Когда вы запускаете программу через прекомпилятор DB2, PRECOMPILEзапускаете вашу программу и, если она находит какой-либо встроенный SQL (в COBOL это блоки операторов, которые переходят EXEC SQLв END-EXEC.), она осторожно извлекает SQL и заменяет его на вызовите интерфейс COBOL-DB2. После этого есть два выхода: PRECOMPILEисточник COBOL, у которого удален весь встроенный SQL ( Aс DBRMэтого момента ), и объект , содержащий весь удаленный SQL ( B).

Прекомпиляция выполняет некоторую базовую проверку синтаксиса, но имейте в виду, что проверки основаны только на объявлениях вашей таблицы в программе. Он не присоединяется к DB2, чтобы проверить это!

Эти два файла полностью разделены, и когда вы запускаете программу COBOL, она должна найти Aи, Bкоторые были сгенерированы одновременно.

На этом этапе Aкомпилируется и связывается со стандартным компилятором COBOL в load moduleи помещается в библиотеку загрузки для последующего использования.

Тем не менее, еще многое предстоит сделать B, DBRM. Это то, где BINDприходит. BINDЭто что-то вроде компилятора для встроенного кода SQL, и вывод "compile" - это package.

Чтобы связать SQL в исполняемый «пакет», процесс BIND подключается к DB2 и выполняет несколько вещей:

• Проверяет, что текущий AuthID авторизован для выполнения привязки.
• Проверяет синтаксис вашего SQL с помощью данных из каталога DB2.
• Наконец, и самое главное, привязка оптимизирует ваш SQL

На последнем шаге весь ваш SQL проходит через Оптимизатор, который учитывает всю статистику и различные пути, которые механизм DB2 может использовать для извлечения ваших данных. Затем он выбирает путь, по которому он придумал, и который связан с наименьшей стоимостью (в более новых версиях DB2 [DB2 10 для z / OS] он может выбрать путь «с более высокой стоимостью», но «с меньшим риском»). Как только путь выбран, он компилируется и становится пакетом, который хранится в каталоге (вы можете увидеть все ваши текущие пакеты с помощью SELECT * FROM SYSIBM.SYSPACKAGE(z / OS)).

И, наконец, последняя часть , которая позволяет нашим программам воссоединиться со своими пакетами, то PLAN. Вы создаете план, выполняя еще одну BIND ( BIND PLAN). План - это набор пакетов, которые программа может просматривать, чтобы найти пакет с одинаковым именем. С COBOL вы указываете, в каком плане программа должна искать, в вашем JCL.

Короче говоря, скомпилированный код проходит через эти шаги для генерации BIND PLAN:

Прекомпиляция -> Создает DBRM (с C [++] прекомпилятор выводит предварительно скомпилированный SQL-файл в файл HFS, который может быть отправлен через программу связывания командной строки ) -> DBRM оптимизирован и набор путей доступа ( a package) создан -> Пакет добавлен в a BIND PLAN, который представляет собой группу пакетов, которые позволяют вам создать «путь поиска» для просмотра ваших программ.

Так как эти программы статически связаны, если статистика вашей таблицы резко изменится, то путь доступа, выбранный оптимизатором во время привязки, может больше не быть лучшим путем, и повторное связывание позволит ему пересмотреть SQL и, возможно, выбрать лучший путь.

Изменить (обновить для комментария): Если вы используете процессор командной строки, вы можете передать либо один пакет связывания (.bnd), либо список имен файлов связывания (.lst). Если вы передаете список, перед именем файла должен стоять знак@(например,/path/to/@packages.lst). Внутри файла .lst вы можете поместить каждый пакет в отдельную строку или разделить их+:

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