DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Автоматический сбор статистики для таблиц.

Почти год назад получилось помочь коллегам в решении такой задачи как автоматизация сбора статистики по колонкам стейджевой таблицы. Суть заключалась в том, что необходимо было создать механизм, позволяющий не беспокоиться администратору или ETL разработчику об изменениях в одной из таблиц промежуточной области (длинное название для стейджа).
Эта таблица, назовем ее, например, CLIENTS, имела обыкновение меняться, путем добавления новых колонок, раз в несколько месяцев. Ввиду разных причин, внедрять изменения часто приходилось прямо на ПРОД системах; чтобы не прерывался ежедневный процесс загрузки данных в DWH, новую колонку просто добавляли к скрипту создания таблицы (у Терадаты, кроме перечисленных особенностей, есть еще и замечательная команда show), а затем пересоздавали таблицу и меняли ETL для загрузки данных из файла.
Конечно, если бы на проекте использовались соответствующие модели для работы с файлами, то проше было бы вносить эти модификации прямо в ODI, а затем уже генерировать изменения в DDL и перегенерировать сценарии, но исторически сложилась другая ситуация, так что механизм автоматического сбора статистики был добавлен в виде дополнений к пакету загрузки таблицы.
Это было сделано с помощью цикла в пакете, когда одна переменная получала очередное наименование колонки, формировала команду подсчета статистики по этой колонке и выполняла ее. Решение не очень элегантное, а главное, оно усложняло понимание логики работы всего пакета загрузки таблицы из файла.
В таких случаях лучше, по возможности, выносить дополнительный код, в данном случае - цикл сбора статистики, в отдельный пакет, делать из него сценарий, а уже затем в пакете загрузки файла вызывать этот сценарий.
Приблизительно в то же время я готовил к публикации заметку об использовании ODI, а вернее, агента ODI, для доступа к данным ETL сервера, в частности, как вывести содержимое файла на экран или получить результат запроса.
И я подумал, что можно было бы обойтись одной процедурой для сбора статистики по заданной таблице. Общий алгоритм действий должен был быть примерно такой:
  1. Получаем доступ к СУБД через открытие JDBC соединения.
  2. Получаем список колонок заданной таблицы через представление dbc.columns
  3. В цикле проходим по всем колонкам и формируем текст операции сбора статистики.
  4. Выполняем запуск команд сбора статистики.
  5. Закрываем соединение.
Вот так примерно выглядит код процедуры:
import string
import java.sql as sql
import java.lang as lang
sourceConnection = odiRef.getJDBCConnection("SRC")
sqlstring = sourceConnection.createStatement()
sqlstmt="select trim(columnname) as col_name from dbc.columns where tablename = '<%=odiRef.getOption( "TableName" )%>' and databasename = '<%=odiRef.getOption( "DbName" )%>';"
sql = 'Collect stats on <%=odiRef.getOption( "DbName" )%>.<%=odiRef.getOption( "TableName" )%> column ('
result=sqlstring.executeQuery(sqlstmt)
while (result.next()):
  sqlstmt2 = sql + str(result.getString("col_name")) + ');'
  sqlstring.executeQuery(sqlstmt2)
sourceConnection.close()
При вызове процедуры из пакета, через опции DbName и TableName передаются фактические наименования таблицы и схемы, в которой она находится.
Обратите внимание, команда odiRef.getJDBCConnection("SRC") обращается к соединению, параметры которого определяются на закладке шага процедуры Command on Source:
Здесь обязательно необходимо указать нужную логическую схему, с которой необходимо будет соединиться. Реальное соединение будет осуществлено с физической схемой в зависимости от выбранного контекста при запуске.
Если же в Менеджере Топологий для заданной пары контекст - имя схемы не будет настроеного соответствия, появится примерно такая ошибка:
com.sunopsis.core.SnpsInexistantObjectException: There is no connection for this logical schema/context pair:WORK / DEV
Доступа у меня к СУБД Терадата в данный момент нет, а проверить как работает процедура, да и улучшить кое-что, хочется. Поэтому попробую сделать сбор статистики для некоторой таблицы Microsoft SQL сервера темой одной из следующих заметок.







jAntivirus