Основы администрирования Informix Dynamic Server Благодарности Я не могу поверить, что окончил еще одну книгу. Всякий раз я говорил себе, что вот она – последняя книга, и вот сейчас я закончил писать эту книгу и начал следующую. Прежде всего, хочу поблагодарить вас за покупку. Есть другие книги, которые вы могли приобрести, но ваш выбор пал на эту. Я могу предположить, что вы купили книгу за свои деньги, а не за счет компании. В этом случае я особенно благодарен. В любом случае надеюсь, что книга пригодится вам как источник ответов на вопросы и для лучшего понимания работы Informix Dynamic Server. Окидывая взглядом промежуток времени с конца 90-х годов по сегодняшний день, могу сказать, что это были прекрасные годы. Компания Informix была приобретена IBM Сообщество Informix выжило и сейчас процветает. Informix расцвел благодаря IBM, Группа разработки IDS сконцентрирована на создании самого лучшего сервера БД для существующих и будущих заказчиков. Это БД-эквивалент выражения «если вы создадите, они придут». Как я писал в предисловии к моей небольшой книге о IDS 11.10, я очень горд, что могу представить работу этой группы. Они создали новые возможности, такие как MACH-11 и значительное повышение производительности, одновременно облегчив администрирование сервера. Я восхищаюсь тем, что будет сделано в новых релизах и насколько лучше станет сервер. Я решил написать эту книгу и ее продолжение, поскольку IBM активно продвигает IDS на рынке. Активные и потенциальные пользователи, а также другие компании-разработчики знают, что IDS возвращается. Я хочу внести свою лепту в поддержку и рост сообщества IDS. Написание книги – нелегкая задача, даже если вы делали это неоднократно. Были и бессонные ночи, и бесконечные вздохи, когда я пытался заставить себя взглянуть в монитор и написать хотя бы страницу. Иногда казалось, что слова сами срываются с пальцев, и я силой заставлял себя пойти спать, чтобы утром добраться до работы. К счастью, мне помогали многие люди. Рискуя забыть кого-то, я все-таки хочу поблагодарить тех, кто сделал выход этой книги возможным. Прежде всего хочу поблагодарить инженеров Informix, которые отвечали на мои вопросы и оказывали техническую поддержку, особенно John Miller, Jonathan Leffler, Jacques Roy, Scott Pickett, Mark Jamison, Guy Bowerman, Amit Dandekar, Charles Gonsalves, Paul-John To. За техническое редактирование спасибо Edgar Sanchez, Mark Jamison, Sudhir Katke, Randy House, Suma Vinod, Sanjit Chakraborty Я всегда буду в долгу у Jacques Roy за его работу. Он написал Java-методы определения размера таблиц. Спасибо Jerry Keesee за то, в своем плотном графике он нашел время и написал предисловие к книге, а также за помощь, которую он мне всегда оказывал. Susan Visser из IBM Publishing всегда была стойким защитником книг по IDS, благодаря ей вышли мои книги по Informix, в том числе и эта. Cathy Elliott – волшебница из мира IBM Marketing. Она всегда оказывала мне всю возможную поддержку, как и Michael Spano – мой менеджер. Мне также помогали многие люди из International Informix Users Group (IIUG), особенно Lester Knutsen, Walt Hultgen, Stuart Litel, Cindy Lichtenauer, Alexander Koerner и многие другие. Если вы с легкостью прочтете книгу, обязательно скажите спасибо Katie Tipton. Я работал со многими редакторами, но Katie – лучшая. Она отредактировала многие мои

бессвязные мысли и логические пробелы в рукописи и исправила синтаксические ошибки, пропущенные мной и техническими редакторами. Jeff Phillips разработал обложку книги и не говорите мне, что обложка не важна. И, конечно, отдельное спасибо моей семье

Содержание Предисловие О книге Часть 1 Введение в Informix Dynamic Server Что такое Informix Dynamic Server Модель Informix Dynamic Server Основные термины Заключение Часть 2 Введение в расширяемость Что такое расширяемость и зачем вам это нужно Расширяемые типы данных Преобразования Определенные пользователем процедуры и агрегаты Функциональные индексы Датаблейды, блейдлеты и другие дополнения Заключение Часть 3 Подготовка к инициализации Логический дизайн базы данных Вычисление размеров таблиц Вопросы, связанные с жестким диском Что использовать для db-пространств – выделенные файлы или сырые устройства Вопросы проектирования db-пространств Настройка ядра Стратегии архивирования Установка окружения Вопросы, связанные с несколькими экземплярами сервера Заключение Часть 4. Установка и инициализация IDS Установка или обновление сервера Изменение конфигурационных параметров Первый запуск экземпляра Системные базы данных

Заключение Часть 5 Основные задачи администратора Утилиты администрирования Informix Изменение рабочих режимов Изменение режимов логирования Управление db- и BLOB-пространствами Создание, перемещение и изменение размеров логов. Автоматический запуск и останов IDS Управление доступом и безопасность Отстрел пользовательской сессии Заключение Часть 6 Создание окружения базы данных Утилита dbaccess Режимы логирования базы данных Создание базы данных Создание и партиционирование(partitioning) таблиц и индексов Ограничения, ссылочная целостность и индексы Внесение информации в базу данных Конкурентность и уровни изоляции Некоторые интересные SQL-запросы Утилита dbschema Заключение Часть 7 Архивирование и восстановление Стратегии архивирования Архивирование логического журнала Устройства для архивирования Как работает процесс архивирования Опции восстановления Использование утилиты ontape Использование ON-Bar и Informix Storege Manager Archecker и проверка архивов Использование Table-level restore Заключение Часть 8 Мониторинг экземпляра Новый интерфейс системного администрирования Утилиты командной строки Мониторинг системы и экземпляра с помощью ОАТ Заключение Приложение

Вступительное слово Если вы держите в руках эту книгу, это значит, что вы открываете или уже открыли для себя самый лучший OLTP-сервер БД. Я не могу назвать себя беспристрастным, так как я – начальник группы разработки Informix, но приобретенная квалификация позволяет мне оценит инновации, внедренные в каждую часть этого замечательного продукта. На протяжении последних 15-ти лет я имел счастье работать с наиболее талантливыми инженерами, сотрудниками поддержки, техническими писателями и полевыми специалистами. За последние десятилетия технологии и аппаратное обеспечение развивались экспоненциально. Стали реальностью SOA, Web 2.0 и 3-D Интернет. На каждом витке развития эта прекрасная группа инженеров и архитекторов предвосхищали требования вашего бизнеса, а также совершенствовали базовые возможности продукта. Эта книга – портал в инновации и функциональность Informix с учетом последних усовершенствований и обновлений. Многолетний опыт автора позволяет ему показать четкую перспективу развития Informix. Я знаю Карлтона на протяжении 10 лет. За это время он написал несколько прекрасных книг по IDS. В Карлтоне присутствует уникальная комбинация глубоких знаний Informix и таланта писателя и преподавателя. Эта книга – прекрасный ресурс и для существующих, и для новых пользователей Informix. Карлтон использует пошаговый подход в раскрытии возможностей Informix – инициализация и инсталляция, архивирование и мониторинг. В книгу также включена информация о последних нововведениях в Informix – вплоть до текущего 11-го релиза. С самого начала в разработку Informix было положено стремление предоставить пользователям OLTP-возможности уровня Enterprise на основе архитектуры с минимальными затратами на администрирование. Другие могут обещать такое, мы уже сделали! Архитектура Informix обеспечивает производительность, возможность создания встраиваемых решений, масштабируемость с минимальными затратами на администрирование. Правильный выбор сервера БД может дать значительные преимущества, и когда принятие решения базируется на технических возможностях, то Informix – выбор лидеров. Возможно, вы даже не знаете, насколько широко используется Informix в мире. Под управлением Informix работают базы данных магазинов, совершаются он-лайновые банковские транзакции и проводится авторизация кредитных карт. Informix используется в службе «911», для бронирования авиабилетов, в системах GPS-навигации, телефонных маршрутизаторах, его применяют Konkan Railway в Индии, финансовые учреждения Китая, крупнейший поставщик молочных продуктов Новой Зеландии. Есть также множество других приложений, но о них я не могу рассказать. Благодаря своей надежности Informix используется для создания mission-critical приложений. Есть возможность создавать приложения 24х7 с надежностью 99.999 и выполнять масштабирование системы на недорогом аппаратном обеспечении. IDS 11 выводит Informix на новый уровень надежности и масштабируемости: кластеры активный-активный могут разделять один диск, есть возможность управлять географически удаленными репликами. Для управления этим функционалом есть понятные GUI-инструменты, позволяющие заказчикам масштабировать систему без сложных аддонов. Редакции Informix есть для всех популярных ОС – Linux, UNIX, Windows, Linux для zSeries и даже для Mac OS X. Наши заказчики и партнеры работают вместе с нами над формированием направлений развития продукта. Написанием этой книги Карлтон выполнил значительную работу по изложению основ администрирования Informix в понятном виде. Он преподносит подарок всем энтузиастам Informix. Наслаждайтесь книгой. Я надеюсь информация, представленная в книге, поможет вам еще раз взглянуть на работу сообщества Informix. Jerry Keesee, начальник отдела разработки Informix

О книге. Поскольку вы читаете книгу, я могу предположить, что вы или администратор базы данных (DBA) , или отвечаете за обслуживание окружения базы данных под управлением Informix Dynamic Server (таких людей я называю администраторами Dynamic Server - DSA). Я не знаю, новичок ли вы в этой работе или уже имеете опыт, и какой именно. Возможно, вы работали с другими СУБД под UNIX, а сейчас хотите установить и администрировать IDS. Если да, то вы откроете для себя новый мир. Или вы в первый раз используете промышленный сервер , а до этого работали с простыми СУБД. Вы устанавливаете IDS, поскольку вам нужны надежность, функциональность, скорость, и хотите знать, что делать дальше. Вы тоже открываете для себя новый мир. Если вы похожи на меня, то, наверное, открытие коробки с дистрибутивом IDS было и возбуждающим, и пугающим. Когда в мои руки попало то, что известно, как самый быстрый и архитектурно правильный сервер на рынке, я был возбужден. Мне не терпелось установить его и оценить производительность. Одновременно я посетил сайт Informix и был устрашен количеством и размером документации. Поверхностный поиск выявил 32 книги и около 9000 страниц только по серверу без учета дополнительных продуктов типа DataBlades. Неужели сервер был настолько сложным, что требовался такой объем документации? На этот вопрос можно ответить и «да», и «нет». Да, сервер Informix сложнее, чем другие СУБД, представленные сегодня на рынке, и имеет больше опций. С другой стороны для запуска и настройки сервера нет необходимости изучать всю документацию. В документации приведено подробное описание того, как работает сервер и почему он работает именно так. Документация IDS подробна , доступна для понимания и заслуживает изучения.

Структура книги В книге я попытался соединить сухие сведения из документации и реальную жизнь. Расположение тем, как мне кажется, соответствует логическому порядку работы с окружением базы данных. Сначала вы спроектируете окружение, затем создадите и наполните его. Будете выполнять архивирование данных, мониторить и настраивать сервер. Это самые важные задачи, и каждая из них разобрана в соответствующей части. Книга не ставит целью объяснить механизмы работы Informix, вместо этого она предназначена для помощи в запуске и управлении СУБД. В книге описаны основные и самые важные задачи администратора, которые выполняются регулярно. В следующей книге «Administering Informix Dynamic Server; Advanced Topics » мы поговорим о репликации, высокой доступности, распределенных транзакциях и других темах, к которым необходимо подробное объяснение. Надеюсь, что вы приобретете и вторую книгу.

Предполагаемая аудитория. Книга написана в расчете на новичков в Informix, а также на тех, кто переходит с ранних версий. Я старался избегать объяснений на уровне битов и байтов. Если вам необходимо понимать работу сервера на таком уровне, стоит обратиться к руководству администратора IDS и другой документации сервера. Большинство того, что описано в книге, есть в официальной документации, поэтому не думайте, что книга сможет ее заменить. Не стоит, однако, полагать, что книга представляет собой обзор документации. Приведенные в книге рекомендации являются результатом долгой работы с Informix. В официальной документации этого нет. При написании книги я руководствовался одним важным предположением – я полагаю, что вы знаете концепции реляционных баз данных, а также что такое таблицы, столбцы и другие компоненты реляционной БД.к этим основам вы сможете добавить знание объектно-ориентированных возможностей Informix.

Краткое содержание Часть 1 – Введение в Informix Dynamic Server Здесь рассказывается о структуре IDS, а также представлены и объяснены ключевые слова, используемые в книге. Часть 2 – Введение в расширяемость Эта часть посвящена объектно-ориентированным возможностям Informix Dynamic Server Часть 3 – Подготовка к инициализации Здесь затронуто множество вопросов по планированию окружения IDS. Разговор, во многом, ведется обобщенно, поскольку нет общих правил построения окружения БД. В конце объясняется, какие переменные окружения и файлы необходимо установить и как это сделать. Часть 4 – Установка и инициализация IDS В этой части описаны все необходимые для создания экземпляра или окружения БД шаги и переменные. Даны рекомендации по значениям самых критичных конфигурационных параметров. В конце приведены данные о системных базах данных IDS. Эта часть более конкретна, в отличии от предыдущих. Часть 5 – Основные задачи администрирования. Здесь мы поговорим о основных ежедневных задачах администрирования экземпляра: о добавлении и освобождении дискового пространства, запуске и остановке экземпляра, отстреле пользовательских сессий. Также в этой части представлены графические инструменты администрирования. Часть 6 – Создание окружения базы данных. Обсуждаются вопросы создания БД и наполнения ее данными: партиционирование таблиц и индексов, логирование, а также некоторые специфические для Informix SQL-запросы, знать которые будет весьма полезно. Часть 7 – Архивирование и восстановление Одна из самых малопривлекательных, но необходимых работ – архивирование БД на ленту или диск. Мы поговорим о различных стратегиях архивирования, их преимуществах и недостатках. Я расскажу, как Informix может выполнять moment-in-time архивирование и восстановление, без необходимости останавливать экземпляр. Подробно рассказывается о использовании утилиты ontape и комплекта утилит ON-Bar совместно с Informix Storage Manager (ISM) Часть 8 – Мониторинг экземпляра На протяжении всей книги вы будете встречать вывод данных мониторинговыми утилитами Informix. В этой части мы сосредоточимся на работе с этими утилитами и поговорим, что необходимо мониторить в первую очередь. В большинстве своем речь

будет идти о утилитах командной строки и функциональности, доступной в новом средстве – Open Admin Tool (OAT) для Informix

Соглашения, принятые в книге

В книге использованы следующие соглашения:

Каждая часть начинается со списка тем, которые будут обсуждаться Каждая часть заканчивается заключением, где приведены наиболее важные

сведения, которые вам необходимо заполнить, а также говорится о том, какие вопросы будут обсуждаться в следующей части

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

Иногда вы будете видеть символ обратного слеша (\). Он используется как маркер продолжения в примерах, которые разбиты на несколько частей. В действительности вам будет необходимо вводить все инструкции одной строкой.

На протяжении книги дополнительная информация будет выделяться с помощью специальных знаков.

Введение в Informix Dynamic Server

В этой части

Архитектура сервера Определение ключевых терминов

В независимости от того, новичок ли вы в Informix или переходите с младших версий вам необходимо знать как управлять сервером и использовать его функциональность. Цель этой книги – сделать процесс обучения более легким путем выделения того, что вам необходимо знать для конфигурирования, запуска и настройки окружения БД. IDS. Хотя на первый взгляд Informix Dynamic Server может показаться похожим на другие СУБД, он очень сильно другой. Вскоре вы убедитесь, что он более стабилен и надежен, проще управляем, чем другие сервера. В книге основное внимание уделяется IDS 11, который в чем-то похож на младшие версии сервера, а в чем-то радикально от них отличается. IDS 11 построен на полностью модифицированной архитектуре, которая была представлена в версии IDS 9.1. Несмотря на все изменения, сервер администрируется во многих случаях так, как и прежде Сегодня IDS - не «классический» сервер БД, скорее это «объектно-реляционный» сервер. Сервер включает в себя высокопроизводительное ядро, разработанное в начале 1990-х годов (и постоянно улучшаемое) для использования преимуществ симметричной многопроцессорной (symmetric multiprocessing SMP) и параллельной обработки (massively parallel processing MPP). Самым большим улучшением было внедрение в сервер объектно-ориентированного функционала в 1995 году, что предоставило разработчикам и администраторам новые возможности по моделированию баз данных и управлению данными. На сегодня IDS предоставляет значительно больше возможностей по сравнению со стандартным реляционным сервером БД. В этой части рассмотрена архитектура сервера и ее три основных компонента. Мы познакомимся со специальной терминологией Informix. После прочтения вы поймете, почему сервер получил свое имя, что такое поток, и из каких фундаментальных частей состоит сервер. Чтение книги предполагает, что вы знакомы с языком SQL и концепциями реляционных и объектно-ориентированных баз данных. В изложении я не буду спускаться до уровня битов и байтов; если вам необходим такой уровень подробности – обратитесь к официальной документации продукта или посетите веб-сайт IBM. Что такое Informix Dynamic Server? Informix Dynamic Server – сервер баз данных или, пользуясь маркетинговым новоязом, «объектно-реляционная система управления базами данных» (object-reletional database management system ORDBMS). Сервер может работать как со стандартными (реляционными) типами данных (числа, символы), так и с объектно-ориентированными. Эта технология является расширением возможности сервера хранить данные не-ASCII в BLOB-объектах. Сегодня IDS позволяет значительно больше, чем просто писать байтовый поток на диск, как это происходит с BLOB. Используя соответствующие функции, вы можете не только хранить «объект», но и искать в нем, изменять что-то и, вообще, выполнять любую операцию, имеющую смысл для этого «объекта» и поддерживаемую функцией. Этот новый функционал обычно называется расширяемость (extensibility). В общем случае задачей сервера БД является обеспечение такой обработки данных (хранение, изменение, удаление), которая защищает данные от компрометации или изменения вне правил, установленных администратором. В IDS включены логические и физические механизмы выполнения этих задач.

С логической точки зрения IDS обеспечивает возможность установить правила и условия не только для столбца в таблице, но и для определения места хранения строки на диске. Вы можете указать условия изменения или удаления элементов строки. Для выполнения различных действий над БД можно использовать хранимые процедуры. С физической токи зрения IDS хранит набор логов, где записаны изменения в данных, и предоставляет механизм блокировок для поддержания целостности данных. Для минимизации простоя в случае поломки оборудования, балансирования нагрузки, обмена данными между различными БД сервер БД позволяет создавать копию всего окружения БД или его части на том же физическом сервере или на отдельном сервере. IDS позволяет выполнять архивирование и восстановление БД. Для отката пользовательской ошибки вы можете выполнить восстановление БД на конкретный момент времени. Недавно в сервер была добавлена возможность восстановления архива, сделанного на одном физическом сервере, на другом физическом сервере даже в том случае, когда сервера используют разные ОС. Informix Dynamic Server разработан на основе динамической масштабируемой архитектуры (Dynamic Scalable Architecture DSA) и позволяет эффективно использовать возможности современных компьютеров – многопроцессорность и большой объем памяти. Исследования показывают, что при добавлении в компьютерных ресурсов (например, установка второго процессора) производительность Informix растет линейно. Основой DSA является распараллеливание процесса (process parallelization) ,или параллельная обработка похожих задач. На рисунке 1.1. показана принципиальная схема работы такого процесса

Рисунок 1.1 Принципиальная схема параллельного выполнения запроса На рисунке показано, как запрос может выполняться параллельно. Сначала происходит несколько операций чтения с диска. Затем над результатами этого шага выполняются функциональные операции. На каждом шаге данных, которые необходимо обработать, становится меньше,и результаты выполнения операции объединяются с результатами выполнения всех операций на этом уровне. Наконец, сервер возвращает результирующий

набор данных клиентскому приложению. Этот алгоритм обработки запроса выполняется быстрее, чем последовательный, когда ожидается выполнение каждогошага перед началом следующего. Кроме выполнения клиентских запросов, IDS также распараллеливает выполнение административных операций – построение индексов, обновление статистики, проверку и, при необходимости, восстановление после сбоя. Такая функциональность Informix требует мониторинга и настройки. Как администратор сервера, вы должны установить необходимые ограничения на параллельную обработку запросов. Более подробно об этом будет говориться в моей следующей книге «Administering Informix Dynamic Server, Advanced Topics». Архитектура IDS позволяет динамически выделять и освобождать необходимые ресурсы «железного» сервера. Например, вы можете сконфигурировать IDS на использование х МБт оперативной памяти, у блокировок и т.п. При увеличении нагрузки IDS попробует выделить себе больше необходимых системных ресурсов. Вы можете ограничить максимальное количество ресурсов, которые IDS может получить. Большинство конфигурационных параметров IDS может быть изменено и в тот момент, когда сервер обрабатывает пользовательские транзакции. IBM дорабатывает эту возможность в каждом новом релизе сервера, и сейчас эта работа близка к завершению. Именно возможность управлять необходимыми ресурсами и администрировать сервер без перезапуска характеризуются словом «dynamic». В дополнение к объектно-ориентированной технологии IDS предоставляет функциональность, которая позволяет эффективно интегрировать прямо в базу данных новые и сложные типы данных. Это могут быть геодезические данные, аудио/видео, XML и другие пользовательские типы. IDS является нейтральным к используемым средствам разработки и поддерживает множество инструментов разработчика под управлением Linux, UNIX, Mac OS X, Microsoft Windows. Модель Informix Dynamic Server Архитектура сервера БД во многом определяет его производительность, масштабируемость, возможность поддерживать новые типы данных. Почти все современные серверы БД построены на устаревшей модели, которая предполагает запуск отдельного процесса для выполнения запросов каждого пользователя. Эта архитектура хорошо работала, если размер БД и количество пользователей были невелики. Сегодня такие сервера БД запускают сотни, а иногда и тысячи, процессов, управлением котороми занимается ОС. Система с одним ЦП может обрабатывать один процесс в квант времени, затем она переключается на другой и так далее. Поэтому процесс пользователя вынужден ждать, когда ОС снова даст ему выполняться. Масштабирование таких систем не зависит от программной составляющей, а зависит только от скорости процессора. Как я упомянул в предыдущем разделе, архитектура Informix (DSA)специально создана для работы с несколькими процессорами и большими объемами оперативной памяти. DSA включает в себя встроенную многопоточность и распараллеливание, динамическое управление памятью. Основными элементами архитектуры Informix Dynamic Server являются:

Процессорный компонент Разделяемая память Дисковый компонент

Давайте рассмотрим каждый из них.

Процессорный компонент IDS обеспечивает возможность масштабировать окружение БД путем настройки пула процессов сервера БД – виртуальных процессоров(VPs). В следующей книге мы рассмотрим механизмы работы этих процессоров. Как можно увидеть на рисунке 1.1., IDS разбивает пользовательские запросы на отдельные подзадачи (сканирование таблиц, объединение, группировка, сортировка), каждая из которых обрабатывается виртуальным процессором. Виртуальные процессоры очень похожи на обычные ЦП тем, как они планируют пользовательские запросы и управляют ими. На рисунке 1.2 показано, как работает пул виртуальных процессоров IDS

Рисунок 1.2 Пул виртуальных процессоров IDS Поток – это отдельная задача в процессе сервера БД. Множество потоков может выполняться одновременно, в параллель, в пуле виртуальных процессоров. В отличие от однопоточного движка, где каждая задача выполняется в свой квант времени, виртуальные процессоры IDS являются многопоточными. Если какой-то поток ждет ресурса или окончил свою работу, то виртуальный процессор сразу переключается на выполнение следующего потока. Таким образом максимально используются ресурсы ЦП. Эта возможность IDS называется «fan-in parallelism» и проиллюстрирована на рисунке 1.3

Рисунок 1.3 «Fan-in parallelism» Пользовательский запрос может быть распределен между несколькими виртуальными процессорами. Например, если выполняется многотабличное объединение (multitable join), сервер БД разделит задачу на несколько подзадач, каждая из которых будет выполняться на своем виртуальном процессоре. На рисунке 1.4 приведена иллюстрация этой возможности, которая называется «fan-out parallelism».

Рисунок 1.4 «Fan-out parallelism»

Суммарный эффект от этих двух типов распараллеливания – за единицу времени выполняется больше операций. Иными словами, сервер БД работает быстрее. Поскольку потоки не привязаны к виртуальным процессорам, IDS выполняет динамическое балансирование нагрузки. Виртуальные процессоры можно объединять в группы, оптимизированные для выполнения какой-то конкретной задачи. Иллюстрация этого факта приведена на рисунке 1.5, где показаны виртуальные процессоры, оптимизированные для операций с ЦП, ввода/вывода, связи, административных задач.

Рисунок 1.5 Виртуальные процессоры IDS, оптимизированные для выполнения отдельных функций. Виртуальные процессоры IDS имеют средства мониторинга, позволяющие отследить деятельность пользователей и сервера БД. В однопоточных серверах БД каждая операция представляет собой независимый процесс в ОС со своими стеком данных, кэшем инструкций, что затрудняет мониторинг того, что происходит в сервере БД. В IDS предусмотрены утилиты onstat и oncheck , которые позволяют легко увидеть, кто и что делает и как это влияет на систему. Вы можете сконфигурировать необходимое количество ВП каждого класса, а также определить специальные ВП (определенные пользователем ВП). Эти ВП выполняются изолированно от ядра сервера, поэтому некорректно функционирующий пользовательский ВП не сможет привести к падению сервера. При необходимости можно изменять количество и тип ВП в то время, когда БД находится в on-line, например, при повышении нагрузки на сервер. В UNIX, Linux, Mac OS X использование многопоточных виртуальных процессоров значительно снижает количество процессов ОС, и как результат, вызывает меньше переключений контекста. В Windows ВП реализованы как потоки и используют многопоточные возможности ОС. Поскольку IDS имеет собственные возможности поддерживать несколько потоков для обслуживания

клиентских запросов, то ему нужно меньше потоков Windows, что снижает затраты ОС на управление потоками. Поскольку IDS полностью использует возможности ЦП, то ему нужно меньше аппаратных мощностей, чем другому серверу БД. В исследованиях выявлено, что чтобы достичь той же производительности, что и однопоточный или процессо-ориентированный сервер БД, IDS необходимо 25-40 % ресурсов Такие возможности IDS позволят вам сэкономить некоторые деньги на закупке и обслуживании оборудования. Разделяемая память Поскольку все задачи сервер выполняет с помощью ВП, то и память сервера БД консолидирована. Этот большой блок разделяемой памяти предоставляет IDS возможность быстро пересылать данные между виртуальными процессорами, а также позволяет пользовательским приложениям получить данные прямо из памяти, если они там есть по запросу другого пользователя, а не дергать лишний раз диск. Память внутри этого блока многократно используется для обслуживания пользовательских запросов. Например, когда сессия пользователя заканчивается, потоко-специфичная память этой сессии очищается и может быть использована в другой сессии. Если для обслуживания пользователей серверу БД необходимо больше памяти, он запрашивает у ОС дополнительную память. Предельный объем памяти, доступной серверу БД, указывается во время конфигурирования IDS. Когда дополнительная память больше не нужна, она освобождается. Динамическое управление памятью позволяет избежать проседания производительности сервера БД при увеличении нагрузки. Освобожденная память возвращается под управление ОС и может быть использована другими процессами. Разделяемая память IDS состоит из четырех частей:

Резидентная часть Виртуальная часть Коммуникационная часть Часть виртуального расширения

Когда стартует окружение БД, выделяются, по крайней мере, две части памяти(управляются конфигурационными параметрами разделяемой памяти и подключений). В Части 4 описаны конфигурационные параметры разделяемой памяти. Ниже кратко описаны части разделяемой памяти IDS Резидентная часть Эта часть содержит, кроме всего прочего, общую информацию об окружении БД и буферный пул. Также в этой части памяти размещены некоторые общесистемные структуры, системные таблицы, содержащие данные о чанках, db-пространствах, блокировках, транзакциях, зеркалах, пользовательских соединениях, буферы физического и логического журнала. Информация из системных таблиц доступна через интерфейс мониторинга системы (System Monitoring Interface см Часть 4 ). В резидентной части разделяемой памяти также располагается буфер репликации HDR (если она запущена). Подробно о репликации HDR смотрите в моей следующей книге. Самую большую часть резидентной области занимают регулярные буферы, используемые для хранения данных, используемых пользовательскими приложениями. В зависимости от характера операций в БД эти буферы могут помочь снизить количество операций дискового ввода/вывода. Когда пользовательское приложение запрашивает некоторые данные, сервер сначала пытается найти их в этих буферах. Увеличение размера пула буферов может сниить количество дисковых операций и тем самым поднять общую производительность системы, особенно для OLTP-приложений. В пуле буферов IDS хранит часто используемые индексные и табличные данные. Для хранения применяется

рейтинговая система. Когда некоторый элемент используется, его рейтинг повышается. Часть буферов хранит часто используемые данные, а другая часть – реже используемые. Для клиентского приложения такая сегментация данных абсолютно прозрачна. Когда данные запрашиваются реже, они перемещаются из буфера часто используемых в буфер реже используемых. В версиях IDS до 10 все буферы в зависимости от версии ОС имели размер 2 Кб или 4 КБ. Размер буфера совпадал с размером страницы диска. В IDS 10 появилась возможность создавать db-пространства с разным размером страниц. Максимальный размер страницы равен 16 КБ. Для каждого размера страницы может существовать только один пул буферов, поэтому если вы создадите три db-пространства с размером страницы 8 КБ, они будут делить один 8 КБ пул буферов. Для управления буферами используются конфигурационные параметры BUFFERPOOL, BUFFERS, LRU и некоторые другие. Сервер БД может самостоятельно управлять эти параметрами. Поскольку в резидентной части разделяемой памяти хранятся пользовательские данные, эта часть памяти существует всегда. Виртуальная часть Содержит стеки потоков, а также пулы памяти для следующих операций и данных

Сортировки данных Кэширования словарей БД, содержащих информацию о таблицах и индексах БД Кэширования данных из функций, определенных пользователем Пула больших буферов для ВП асинхронного ввода/вывода (AIO VP) Хранения откомпилированных версий хранимых процедур «Глобального» пула Некоторых таблиц мониторинга окружения.

В виртуальном разделе также хранятся кэшированные планы для оптимизатора IDS. В большинстве OLTP-приложений в течении операционного дня выполняются одинаковые SQL-запросы с немного разными условиями (например, в запросе меняется идентификационный номер контрагента). Для выполнения запроса сервер БД строит план, как быстрее всего получить требуемые данные. Если данные уже находятся в буфере, то они считываются оттуда, если нет, то требуется обращение к диску. В этом случае оптимизатор строит план выполнения запроса. Оптимизатор ищет подходящий индекс (если есть), строит список db-пространств, которые необходимо просмотреть и т.д. Этот процесс незаметен для пользователей, но от него зависит время отклика системы. Informix имеет механизм кэширования плана. В кэше может храниться план выполнения запроса для использования этого плана последующими такими же запросами. Эта область памяти хранит сам SQL-запрос и информацию, необходимую оптимизатору для быстрого выполнения запроса. Вы можете сконфигурировать размер кэша и время попадания плана в кэш (например, после выполнения двух запросов). В большинстве случаев, чтобы не хранить в кэше план одиночного запроса, план помещается в кэш после выполнения запроса три или более раз. Если вам необходимо обновить планы выполнения запросов, вы можете очистить кэш. Например, это можно сделать после выполнения команды update statistics. Еще один интересный элемент виртуальной части – пул больших буферов. Предыдущие версии сервера имели два типа буферов – регулярные и большие. Регулярные буферы были очень похожи на буферы, хранимые в резидентной части разделяемой памяти. Большой буфер имел размер 8 страниц и использовался для буферирования больших последовательных объектов, например, блобов. В последней версии IDS для каждого AIO ВП (ВП асинхронного ввода/вывода) выделяется большой буфер. Размер буфера определяется ОС, но он значительно больше,

чем в предыдущих версиях IDS. Буфер такого размера полезен при выполнении обработки контрольной точки (checkpoint) и для чтения большого объема данных при выполнении сложных аналитических запросов. После того, как данные помещены в большой буфер, для использования они перемещаются в буферный пул в резидентной части памяти. BLOB-объекты Informix читает и пишет через большой буфер, а не через резидентную часть памяти. Ниже в этой части мы рассмотрим уже использованную терминологию – страница данных, контрольная точка, BLOB. В зависимости от выполняемых сервером задач, объем виртуальной части памяти может меняться. Как я говорил выше, это динамическая часть памяти. Начальный размер виртуальной части памяти настраивается конфигурационным параметром SHMVIRTSIZE. Параметр SHMADD определяет размер дополнительно запрашиваемой памяти, а параметр SHMTOTAL указывает, сколько всего разделяемой памяти может запросить сервер. Виртуальная часть разделяемой памяти существует при работе любого сервера Informix. Коммуникационная часть Существует только в том случае, если настроено соединение с сервером через разделяемую память. Вы должны определить каждый необходимый вам протокол соединения с сервером IDS. Если вы включите протокол соединения через разделяемую память, приложения, выполняющиеся на одном железном сервере с IDS, будут соединяться с Informix через разделяемую память. В части 4 мы рассмотрим возможные протоколы соединения с сервером и параметр NETTYPE. В двух словах, при использовании сетевых протоколов для связи с IDS обмен данными между сервером и приложением идет через глобальный пул виртуальной части разделяемой памяти. Часть виртуального расширения Эта часть разделяемой памяти выполняет две функции. Здесь UDVP (определенный пользователем ВП) выполняет DataBlade или определенную пользователем функцию (UDR). Такой подход защищает сервер от падения из-за «кривой» UDR. Наличие этого раздела разделяемой памяти зависит от конфигурации сервера БД. Дисковый компонент В большинстве инсталляций IDS на UNIX и UNIX-подобных ОС сервер БД управляет обменом с дисками самостоятельно без участия ОС. В большинстве случаев данные хранятся на разделах диска без файловой системы – так называемые, сырые устройства (raw disk space). Данные с таких разделов читаются и пишутся с использованием прямого доступа к памяти (direct memory access DMA) и последовательного доступа к сырым устройствам (raw sequential access method RSAM). Механизм RSAM обеспечивает большую, по сравнению с использованием файловой системы UNIX, производительность. Если ОС поддерживает механизм асинхронного ввода/вывода (KAIO), то производительность вырастает еще больше. KAIO – это возможность процесса одновременно выполнять несколько операций дискового ввода/вывода без необходимости ожидать отклика от подсистемы ввода/вывода. База данных может быть размещена в файлах ОС (выделенное пространство cooked space). Использование выделенных файлов не гарантирует, что они будут расположены на диске последовательно. Вы должны исходить из предположения, что не будут. Эта особенность выделенных файлов влияет на производительность работы с диском. Некоторые операционные системы (типа Windows) для записи /чтения файлов используют небуферизированный и некешированный ввод/вывод. Из этого факта следует вывод: использование сырого диска под Windows выигрыша в производительности не принесет. С версии IDS 11 поддержка небуферизированного ввода/вывода средствами ОС переносится и на другие операционные системы. Эта функциональность может

обеспечить производительность, сопоставимую с производительностью сырого диска, при использовании файловых чанков и db-пространств. Ради справедливости скажу, что этот функционал IDS не является уникальным. Некоторые серверы БД поддерживают хранение Баз данных только в выделенных файлах, другие поддерживают и выделенные файлы, и сырые диски. У IDS есть очень полезная возможность – распределять данные на диске в соответствии с некоторыми правилами. Informix поддерживает несколько схем партиционирования данных. Наличие такого функционала также повышает доступность данных, улучшает управляемость хранением старых данных (это называется data life-cycle management – управление жизненным циклом данных). В Informix диск представлен некоторыми физическими и логическими свойствами. для понимания этого я ниже ввожу необходимую терминологию. В Части 3 мы более подробно поговорим о дисковом компоненте. Основные термины. На протяжении книги я буду использовать некоторые фразы и слова, которые или имеют смысл только для Informix Dynamic Server, или трактуются в нем не так, как в других серверах БД. Поэтому перед тем, как двинуться дальше, давайте определимся с ключевыми терминами. Для избежания двусмысленности, я буду стараться использовать только правильные термины и избегать компьютерного сленга. В книге я буду постоянно обращаться к «экземплярам» и иногда к «серверу БД». Сервер БД – это откомпилированный исходный код, на использование которого вы приобрели лицензию и установили на физический сервер; это Informix Dynamic Server. Этот сервер имеет утилиты и программы для создания, администрирования сервера и подключения к нему клиентских приложений. Вам, возможно, вообще не придется администрировать и настраивать сам сервер. При правильной настройке файловой системы и переменных окружения на физический сервер можно установить несколько версий IDS, о чем мы подробно поговорим в части 3. Экземпляр – уникальное рабочее окружения или окружение времени выполнения, используемое для хранения набора баз данных, к которым могут иметь доступ (или не иметь) конечные пользователи. До этого момента в книге вместо термина «экземпляр» использовался термин «окружение базы данных». Экземпляры и базы данных настраиваются для достижения необходимой производительности. Изменения рабочего окружения базы данных проводятся на уровне экземпляра. Физический сервер, на который установлен сервер БД, может поддерживать несколько экземпляров. Каждый экземпляр обладает своим набором конфигурационных параметров, памятью и дисковым пространством. Физические элементы Чтобы понять, как физические элементы объединяются в логические структуры, давайте рассмотрим рисунок 1.6. на нем сплошные линии соответствуют физическим элементам, а пунктирные – логическим.

Рисунок 1.6. Физические и логические структуры экземпляра IDS Базовый физический элемент экземпляра называется страница данных или просто страница. Страница данных имеет фиксированный размер, называемый размером страницы; размер страницы – минимальный объем данных, который может быть записан на диск или считан с диска. Как я говорил выше, в зависимости от версии ОС размер страницы может составлять 2 КБ или 4 КБ. Большинство утилит мониторинга и администрирования IDS выводят информацию об использовании дискового пространства в страницах, а не в килобайтах или мегабайтах. Для приведения этих данных к мегабайтам необходимо количество страниц умножить на 2 (4,6,8,12,16). Самый маленький дисковый компонент, который вы можете администрировать, называется чанк. С физической точки зрения чанк – это обычно целый дисковый раздел, хотя может быть и меньше раздела, но обязательно должен быть логически непрерывным (подробнее смотрите часть 5). Если для хранения данных вы используете выделенные файлы, то чанк представляет собой обычный плоский файл. С логической точки зрения чанк представляет собой набор страниц данных и является базовым элементом для создания db-пространств и добавления в них дополнительного пространства. DB-пространство – логический набор из одного или более чанков, созданных на одном или нескольких физических дисках. В db-пространствах хранятся таблицы баз данных. Если вы не сконфигурировали параметры, определяющие сортировку и упорядочение результатов выборки в памяти, то эти операции проводятся с использованием диска. DB-пространства не могут разделяться между несколькими экземплярами, а физический диск, на котором расположены чанки, может содержать чанки, принадлежащие другим db-пространствам или экземплярам, расположенным на том же физическом сервере (см. рисунок 1.7)

Рисунок 1.7. Пересечение чанков db-пространств нескольких экземпляров Каждый из трех дисков, показанных на рисунке разделен на четыре раздела. Эти разделы (или чанки) использовались для создания db-пространств трех экземпляров сервера (danube, madeira, sarthe). DB-пространство Danube_1 создано из чанков ,расположенных на разных дисках (диск 2 и диск 3). В процессе создания db-пространства вы должны указать его первый чанк. Потом, при необходимости вы можете добавить чанки в db-пространство, а также удалить их. Начальный чанк db-пространства не может быть удален; вы должны удалить все db-пространство и выполнить полное архивирование базы данных. Итак, экземпляр – это автономное пространство для обработки данных, состоящие из db-пространств, где хранятся базы данных, временных пространств и предварительно скомпилированных функций (хранимые процедуры и определенные пользователем функции). Как вы увидите ниже, экземпляр имеет имя, под которым он известен в сети, и конфигурационные параметры, определяющие, как работает этот экземпляр. Элементы экземпляра. Экземпляр содержит в себе несколько структур данных, от которых зависит его работа. Корневое db-пространство(rootdbs) – это сердце экземпляра. Это db-пространство содержит всю информацию об экземпляре и, кроме того, может использоваться для выполнения некоторых операций, если в других db-пространствах экземпляра для этих операций не хватает места. Повреждение корневого db-пространства приводит к недоступности всего экземпляра; это же справедливо и для логического и физического журнала. Физический журнал содержит исходные образы страниц. Журнал используется в том случае, если необходимо отменить изменения, внесенные в данные. Логический журнал содержит исходные образы страниц, а также в него записываются изменения данных и фиксируется, были ли эти изменения записаны на диск. Без этих двух журналов экземпляр не работает. Термины баз данных Наверное, вы уже представляете, что такое реляционная база данных. Вы понимает, что данные хранятся в столбцах и что набор столбцов образует строку. Строки группируются в таблицы и на основе ключевых или важных столбцов для ускорения поиска данных могут быть построены индексы. Кроме числовых и символьных типов данных, общих для всех реляционных СУБД, вы можете использовать «нестандартные» или, в терминологии IDS, расширенные типы данных. Вы можете создавать типы данных, необходимые именно вашему приложению. Так как IDS поддерживается объектно-ориентированный подход, элементы, от столбца до таблицы, могут иметь поддержку наследственности и другого функционала, недоступного

в чистой реляционной СУБД. Используя эту возможность, можно использовать традиционные элементы данных новыми методами, недоступными в реляционной модели данных. В IDS также включены большие двоичные объекты (binary large objects) или BLOB-ы. Существует два типа BLOB-ов – простые и смарт-BLOBы (simple and smart). Простые BLOBы являются с точки зрения сервера черным ящиком. Смарт-BLOBы состоят из типов данных, которыми сервер БД может манипулировать, используя функционал, добавленный в экземпляр. Этот функционал может браться из DataBlade, bladelet или вашей собственно определенной пользователем функции (UDR). Ниже мы рассмотрим этот вопрос более подробно. Преимущество BLOBов в том, что большие объемы данных могут хранится одним непрерывным блоком без разбиения их на куски фиксированной длины. BLOB-объекты могут храниться в специально настроенных db-пространствах (BLOB-пространства). Как и в случае с BLOB-объектами, существует два типа BLOB-пространств – простые BLOB-пространства (обычно называются BLOB-пространства) и смарт BLOB-пространства. BLOB-пространства не слишком отличаются от обычных db-пространств, особенно сейчас, когда появилась возможность создавать обычные db-пространства с разным размером страницы. BLOB-пространства были первыми db-пространствами с переменным размером страницы, то давало возможность хранить BLOB на одной BLOB-странице. Смарт-BLOBы отличаются тем, что их хранение и извлечение управляется с помощью метаданных, хранимых в смарт BLOB-пространстве. В части 5 мы поговорим о создании обоих типов BLOB-пространств. BLOB-объекты делятся на два больших типа – текстовые и двоичные. Текст-ориентированные BLOBы представляют собой документы в некоторой форме. Я работал с инсталляциями Informix, где в BLOB-ах хранились документы вместе с контрольными кодами. Когда из таблицы выбиралась строка, BLOB-столбец этой строки передавался как параметр скрипту, который запускал программу обработки текста. Для сохранения документа в БД пользователь запускал макрос, который записывал документ обратно в базу (используя SQL-команду insert или update). Таким же образом можно работать и с двоичными BLOBами. Двоичными BLOBами являются оцифрованные звук и видео, картинки и т.п. Интерпретацией информации из двоичных BLOBов должно заниматься клиентское приложение. Как говорилось выше, таблицы с данными хранятся в db-пространствах, состоящих из чанков. Чанки могут располагаться на сырых устройствах – дисковых разделах без файловой системы и в выделенных файлах. Физические сегменты, выделяемые для хранения данных таблицы, называются экстентами. Ориентируясь на ожидаемое количество строк в таблице, вы можете выделить экстент достаточного размера для хранения данных таблицы в логически непрерывном пространстве. Если база хранится в выделенных файлах, экстент не будет физически непрерывным, а если на сырых устройствах, то будет. Когда табличный экстент заполняется данными и требуется дополнительное место, сервер выделяет таблице новый экстент. Если в db-пространстве находится несколько таблиц, то новый экстент может не быть добавлен сразу вслед за заполненным. На рисунке 1.8 показан случай разделения экстентов одной таблицы экстентами других таблиц.

Рисунок 1.8 Пересечение табличных экстентов Большое количество пересекающихся экстентов неблагоприятно влияет на производительность чтения данных. В части 8 мы рассмотрим команду, которая позволяет узнать о количестве пересечений экстентов в db-пространстве. Таблица может как находится целиком в одном db-пространстве, так и быть распределена по разным db-пространствам. Такой процесс называется фрагментированием или партиционированием таблицы. Таблица – не единственный объект, который можно фрагментировать, индексы также имеют опции фрагментирования. Грамотное фрагментирование таблиц и индексов может существенно улучшить производительность сервера. В части 5 мы детально поговорим о фрагментировании таблиц и индексов. Типы окружения базы данных. Окружения базы данных разделяют на две большие категории. OLTP-системы характеризуются большим количеством операций чтения/записи, обслуживают большое количество пользователей, выполняющих однотипные операции в базе данных и обеспечивают минимальное время отклика. Большинство бизнес-приложений являются именно OLTP-приложениями, например, системы обработки заказов. IDS прекрасно подходит для работы в качестве OLTP-сервера. OLAP-, или DSS-системы характеризуются гораздо меньшим количеством пользователей, однако, эти пользователи выполняют сложные запросы, часто за большие интервалы времени и не так требовательны ко времени отклика системы. Хотя IDS в наибольшей степени подходит для OLTP, многие заказчики используют его и в DSS, из-за наличия масштабируемости, расширенных типов данных, производительности и небольших затрат на администрирование. Транзакции Иногда необходимо, чтобы в базе данных выполнился или весь набор операций, или не выполнилось ничего. Такая группа операций называется транзакцией. Типовым примером транзакции является перечисление денег в банке. Предположим, что вы хотите перечислить деньги со счета на счет. В этом случае деньги должны быть сняты с одного счета, а затем зачислены на другой счет. Если одна из этих операций завершится неудачно, то должны быть откачены обе. Когда я объяснял концепцию корневого db-пространства, то упоминал о том, что сервер отслеживает операции в базе данных, используя два компонента на диске – физический и

логический журнал. Физический журнал содержит исходный образ данных, которые будут изменяться. Когда данные модифицируются или удаляются, сервер записывает эти изменения в логический журнал. Если вернуться к нашему банковскому примеру, можно сказать, что когда обе операции выполнены, то транзакция зафиксирована(committed). Исходные значения и их изменения записаны в текущий логический журнал и транзакция помечена как завершенная. Если произошла ошибка, то сервер откатывает(roll back) транзакцию и использует данные физического журнала для восстановления исходных данных. Контрольные точки (checkpoints) Данные, находящиеся в разделяемой памяти, должны периодически записываться на диск. Это необходимо для сохранения целостности данных. В некоторых случаях данные записываются на диск автоматически в конце выполнения задачи; в других случаях запись осуществляется как часть обработки контрольной точки (checkpoint). Во время обработки контрольной точки данные на диске обновляются так, чтобы соответствовать данным, находящимся в разделяемой памяти. В предыдущих версиях IDS во время обработки контрольной точки остальные операции в базе приостанавливались на короткое время; это было необходимо для корректной обработки критически важных данных экземпляра и для записи данных на диск. В версии IDS это время значительно уменьшено. Пользователи не должны заметить прерывание в работе экземпляра. После завершения обработки контрольной точки сервер находится в логически целостном состоянии (logically consistent state). Более детально об обработке контрольной точки мы поговорим в следующей книге. Заключение В этом разделе дано общее описание архитектуры Informix Dynamic Server и приведен обзор основных терминов, относящихся к Informix. После прочтения вы должны знать о трех основных компонентах архитектуры IDS, как сервер работает с разделяемой памятью и что содержит каждая часть разделяемой памяти. Вам должна быть понятна основная терминология, разница между сервером и экземпляром, а также, что такое чанк и db-пространство, в чем разница между OLTP и DSS, что такое BLOBы и контрольные точки. Я несколько раз отмечал, что IDS отличается от остальных серверов БД с точки зрения используемой архитектуры и функциональной перспективы. В этой части рассказывалось о архитектурных отличиях. В части 2 мы поговорим на функциональных усовершенствованиях, доступных в IDS в результате интеграции объектно-ориентированного подхода к БД Illustra с динамически масштабируемой архитектурой IDS.

Часть 2

Введение в расширяемость В этой части Что это такое и зачем оно надо Новые объекты базы данных и как их использовать В 1995 году произошли два события, на которые в Informix возлагали надежду, что они вознесут компанию на первое место на рынке СУБД. Первое событие – начало всеобщего доступа к Интернет. Технология World Wide Web, разработанная в CERN, начала свое глобальное распространение и люди начали изучать новые пути получения информации. Второе событие – компания Informix внесла серьезные обновления в Informix Dynamic Server. Продукт, получивший название Universal Server, рассматривался в качестве родоначальника следующего семейства серверов БД, разработанных и оптимизированных для «поколения Интернет». Universal Server был результатом долголетнего проекта по объединению объектно-ориентированной БД, разработанной Майклом Стоунбрекером (Michael Stonebraker) в проекте Illustra Server, и динамической масштабируемой архитектуры IDS. В последующие год или два другие компании выпустили нечто подобное, но в их случае все ограничилось объектно-ориентированным именованием функций, которые по прежнему работали с данными, используя стандартные реляционные операции. Informix провел восхитительную демонстрацию возможностей. В базу могли быть загружены фотографии, видео, аудио, и их можно было обрабатывать как объекты базы (например, получать запросом цвет, тип фигуры), не прибегая к хранению метаданных объекта в текстовых столбцах. Были возможности по автоматической генерации Web-страниц из базы данных, без необходимости писать статические HTML-страницы. Будущее представлялось мультимедийным (мое примечание - типа великого гула о Web 2.0) Прошло 10 лет. Вычислительный ландшафт поменялся. Графические и Web-интерфейсы стали нормой и там, где это необходимо, мультимедийными. В продаже предлагается Universal Server со всеми своими плюшками. К моменту, когда вы будете держать эту книгу в руках, срок поддержки IDS 7 подойдет к концу, и вы не сможете приобрести строго реляционную версию сервера. Для всех возможных целей IDS 11 гораздо быстрее, чем IDS 7, поэтому нет смысла оставаться на старой версии. Вы можете сказать, что новый функционал вам абсолютно не нужен и вам достаточно стандартных типов данных. Я вам возражу, что, хотя в IDS добавили расширенную поддержку аудио/видео и прочих сложных типов данных, объектно-реляционная технология предоставляет впечатляющие возможности и при работе со стандартными типами данных. IDS позволяет вам использовать стандартные типы данных способами, недоступными для стандартных реляционных серверов. В этой части поясняется, что такое «расширяемость» в понимании Informix Dynamic Server, рассмотрены ее компоненты и методы использования в приложениях. Что это такое и зачем оно надо Текущая версия IDS представляет собой интеграцию двух уникальных технологий. Началось все с правительственного агентства, которое занималось сложным анализом. Вес стандартные данные хранились в базе данных под управлением Informix, а «сложные» данные (всякие научные снимки) – в объектно-ориентированной БД. Объектно-

ориентированным окружением был Illustra Server, разработанный Майклом Стоунбрейкером (Michael Stonebraker) – пионером в области объектных баз данных. Ему удалось создать промышленный сервер, где элементы данных были не статическим, а имели объектно-ориентированные свойства, такие как наследование, что позволяло создать новый тип данных на основе старого и добавить к новому типу свойства, которых не было у старого. Сервер мог работать с новым типом данных, используя написанные для этого типа функции, а не выгружать такой объект во внешнее приложение. Именно так в агентстве использовался Illustra Server: для хранения информации были созданы специальные типы данных и написаны функции их обработки. Наличие этих функций позволило использовать для обработки данных стандартные SQL –операторы и проводить обработку непосредственно на мощном сервере, а не на клиентском ПК. На тот момент IDS не хватало возможностей манипулирования со сложными типами данных, но он был самым быстрым сервером для выполнения стандартных операций с данными. Illustra Server выполнял стандартные операции значительно медленнее, но обладал объектным функционалом. В результате агентство ежедневно занималось объединением данных, хранимых в базах под управлением двух серверов. Заказчики не стеснялись высказывать свои пожелания касательно разработки одного продукта, в котором было бы сосредоточено все лучшее из этих двух серверов. Informix приобрел Illustra и начал многолетний проект по интеграции этой технологии в DSA. На данный момент Informix является лидером на рынке СУБД по объектно-ориентированным возможностям. Некоторые игроки на рынке СУБД заявляют, что у них тоже есть такие возможности, но из руководств по эти продуктам следует, что в этих серверах используются стандартные хранимые процедуры и представления для создания видимости, что элементы данных обладают объектно-ориентированными возможностями. В другом случае производители СУБД разработали дополнительные серверные продукты, которые устанавливаются в дополнение к реляционному серверу и обмениваются с ним данными через API, что ведет к снижению общей производительности и масштабируемости системы. Итак, что такое расширяемость? Расширяемость – это возможность «расширить» функциональность сервера по манипулированию данными. Эта возможность включает в себя создание типов данных, которые наиболее точно описывают эти данные, процедур манипулирования этими данными, наследования характеристик, перегрузки функций, полиморфизма и т.д. наличие такой функциональности дает возможность разработчикам и администраторам создавать базы данных и приложения по управлению данными согласно бизнес-правилам. Когда данные создаются и хранятся согласно бизнес-правилам, приложения могут использовать эти данные более эффективно, что ведет к более быстрой разработке таких приложений, уменьшению ошибок, лучшей производительности. Имея возможность создавать собственные типы данных, вы можете решать проблемы, которые решаются стандартными методами крайне неэффективно или не решаются вообще. Правильное использование этой технологии подразумевает, что разработчик и администратор могут научиться мыслить по-другому. Они должны быть способны видеть данные и сточки зрения реляционной алгебры, и с точки зрения бизнеса. Например, реляционные правила рекомендуют хранить данные о заказе в разных таблицах, но если бизнес рассматривает эти данные как один объект, то в базе лучших их хранить именно как один объект. Разработчика и администраторам следует использовать эти возможности, а не рассматривать сервер БД только как место хранения данных. Сегодня термин «портируемость» повторяют как мантру, предполагая, что всю работу с данными должно выполнять конечное приложение, а сервер БД рассматривают как хранилище данных, которые не нужны в данный момент. При таком раскладе серверу БД уделяют очень мало внимания или не уделяют вообще. Такой подход обеспечивает гарантии постоянной занятости для разработчиков клиентских приложений, но приводит к массе проблем – увеличению времени разработки приложений, снижению

производительности, поскольку многие операции выполняются не на мощном сервере, а на клиентском ПК, экспоненциальному увеличению сетевого трафика и т.д. правильное использование возможностей IDS может значительно уменьшить количество таких проблем, а то и вообще избежать их. Расширяемость – стандартная возможность IDS, но она вам не навязывается. Если она вам не нужна – не используйте. Расширяемость предназначена не только для мультимедийных приложений, она может использоваться и в «стандартных» приложениях. Давайте рассмотрим пример. Задачи, решаемые с помощью расширяемости , — организационная диаграмма. Рисунок 2.1 иллюстрирует типичный для многих организаций вопрос – кто кому подчиняется.

Рисунок 2.1. Аналоговое представление структуры подчиненности департамента Представление в таком формате удобно и позволяет быстро определить, кто кому подчиняется. но обрабатывать такую структуру данных с помощью стандартной базы данных очень-очень сложно. Стандартные правила моделирования разрешают только отношение главный-подчиненный (master-detail), которое прекрасно срабатывает в случае президента компании, но не работает на уровне вице-президента и ниже, так как на этом уровне и ниже мастер-запись является частью подчиненной записи мастер-записи более высокого уровня. Для решения этой проблемы в таблице используют внешний ключ на эту же таблицу, например, так: create table employee ( employee_id serial unique, manager_id integer primary key, … ) foreign key (employee_id) references manager_id

А затем разработчики клиентского приложения получают увлекательную задачу – придумать метод доступа к таким данным. Разработчики имеют две возможности – использовать рекурсивный обход дерева или обработку множеств. Если использовать рекурсивный подход, то программа должна уметь генерировать динамический SQL для выбора лиц, подчиненных указанному менеджеру, затем для выбора подчиненных этих подчиненных и т.д. Отдельный SQL-запрос крайне прост: select employee_name, employee_id from employee where manager_id=? Такой подход серьезно просаживает производительность, поскольку с увеличением количества уровней вложенности время выполнения запроса растет экспоненциально. Кроме того, программа должна хранить промежуточные результаты на каждой итерации, а в конце объединить их все. Подход, ориентированный на работу с множествами значительно лучше. В этом случае программа должна динамически генерировать примерно такие запросы для каждого уровня иерархии в организации: select count(*) from employee e1, employee e2, employee e3, employee e4, employee e5 where e5.manager_id=? and e4.manager_id=e5.employee_id and e3.manager_id=e4.employee_id and e2.manager_id=e3.employee_id and e1.manager_id=e2.employee_id с каждым новым уровнем вложенности сложность запроса возрастает и производительность падает. Короче говоря, ни тот, ни другой подход не обеспечивают быстроты и эффективности. Используя средства расширения IDS, мы можем представить данные именно в таком иерархическом формате. Чтобы это сделать, нам надо зарегистрировать в системе Node DataBlade. После этого, нам станет доступен новый тип данных (node) и набор процедур для работы с ним. Новый тип будет использоваться в базе данных точно также, как и встроенные типы данных. Используя тип данных node и поддержку сервером длинных имен объектов, мы можем добавить столбец employee_reporting_structure в таблицу employee. В этом столбце могут храниться данные о позиции сотрудника в организации, и такой ключ может быть использован для поиска связей между сотрудниками: create table employee ( employee_id serial, employee_reporting_structure node primary key … … ); На рисунке 2.2. представлена иллюстрация такого подхода

Рисунок 2.2 Использование DataBlade-а node для моделирования иерархических данных. Как видно из рисунка, каждый элемент структуры имеет свой уникальный идентификатор. Смежные уровни представляют собой связь начальник-подчиненный. Значение 1.4.3.4 означает, что сотрудник №4 отчитывается перед менеджером №3, у которого, в свою очередь, начальник – это менеджер №4, а у менеджера №4 начальником является менеджер №1. При такой постановке задачи вопрос о подчиненности объектов становится тривиальным: какой из них больше. Является ли один объект прародителем, родителем, потомком другого? На этот вопрос ответят функции ,включенные в состав Node DataBlade. Для поиска начальника любого сотрудника в организации будет использоваться запрос типа такого: select ischild() from employee where employee_reporting_structure= (select employee_reporting_structure from employee where employee_id=input_value) Другие функции позволят вам добавлять уровни, разделять, получать список элементов определенного уровня и т.д. Тип данных node может быть проиндексирован, следовательно, операции с ним будут иметь линейную производительность. Это один из примеров, демонстрирующий, как расширяемость может помочь решить задачи, трудно решаемые на классическом реляционном сервере. Используя функциональность IDS, вы можете решать бизнес-задачи, решать которые раньше было невозможно или очень тяжело. Теперь давайте рассмотрим некоторые аспекты объектно-реляционной технологии IDS. Начнем с расширенных типов данных. Расширенные типы данных. Как можно увидеть на рисунке 2.3 в Informix типы данных разделяются на две большие ветви – встроенные типы и расширенные типы.

Рисунок 2.3. Дерево типов данных IDS Ветвь встроенных типов инкапсулирует стандартные типы данных, которые поддерживаются всеми серверами БД. Расширенные типы данных разделены на несколько типов, в зависимости от их функциональности. В последующих разделах мы рассмотрим эти типы подробнее. Реляционные типы данных. В левой части рисунка 2.3 представлены реляционные типы данных, с которыми в, наверняка, знакомы,: character, varchar, integer, float, decimal и т.д. в них нет ничего уникального. Целочисленные типы данных имеют размер от 2 байт (small integer) до 8 байт (integer) и могут представлять числа в диапазоне от –9,223,373,036,854,775,807 до 9,223,372,036,854,775,807. полагаю, что такого диапазона хватит для хранения номер заказов и идентификаторов покупателей. Для обеспечения уникальности на столбец типа bigserial и serial необходимо наложить ограничение уникальности (unique constraint). В таблице одновременно может столбец и bigserial и serial Символьные данные бывают двух типов – длиной до 255 символов(varchar) или до 2Кбайт(lvarchar). Тип varchar может индексироваться, а lvarchar – нет. В IDS также есть расширения для этих типов данных. С помощью указания длины N строки тип lvarchar(N) в зависимости от ОС может хранить до 32 Кбайт символьных данных. Хранение символьных данных такой длины в символьном столбце является предметов постоянных споров. Я считаю, что в этом случае предпочтительнее использовать smart BLOB, который может индексироваться. Я полагаю, что создание индекса для 32 Кбайтного символьного столбца – не лучший подход, но решать вам. Для хранения даты и времени используется тип данных datetime. Применяется также подход, основанный на хранении интервала времени между двумя значениями даты и/или времени. Типы decimal и float характеризуются точностью до и после точки и т.д. Расширенные типы данных Некоторые из этих типов могут вас смутить, особенно если знать, что они могут вкладываться друг в друга. Комплексные типы данных Если попытаться объяснить назначение этих типов данных в двух словах, то можно сказать так: они позволяют хранить повторяющиеся наборы значений в одном столбце и свернуть таблицу в один столбец.

Тип данных строка (row data type) Этот тип данных похож на структуру (struct) в языке С. Используя этот тип, вы можете сгруппировать логически связанные элементы в один столбец. Иначе говоря, можно свернуть таблицу в строку. Строка может быть именованной и неименованной (named row, unnamed row) Именованная строка существует на уровне базы данных, как и реляционные типы, которые вам более известны. Именованная строка может использоваться для создания таблицы, состоящей из одного столбца, а может быть одним из нескольких столбцов в таблице. В листинге 2.1. приведен пример использования именованных строк. create row type name_t ( fname varchar(20), lname varchar(20) ); create row type address_t ( street_1 varchar(20), street_2 varchar(20), city varchar(20), state char(2), zip char(9) ); create table student ( student_id serial, name name_t, address address_t, company varchar(30) ); Листинг 2.1. Пример использования именованных строк. В этом примере создано две именованных строки. Такой подход может использоваться в базе данных там, где необходимо хранить набор данных сгруппированным. Например, вам необходимо создать модуль для управления школой, где будет информация об учениках и уроках. Вы можете создать таблицу student и использовать именованные строки, как показано в Листинге 2.1 Неименованные строки менее типизированы и могут использоваться только в таблице, для которой они определены. Они не могут использоваться для создания таблицы, состоящей из одного столбца. В Листинге 2.2. приведен пример. row (a int, b char(10)) row (x int, y char(10)) create table part (part_id serial, cost decimal, part_dimensions row (length decimal, width decimal, height decimal,

weight decimal (6,2)) ); Листинг 2.2. Пример неименованных строк. Два типа данных row, использованные в этом примере, функционально идентичны, несмотря на различие в именах. Если тип данных «неименованная строка» используется в разных таблицах, то имена переменных этого типа могут быть одинаковы. Если тип «неименованная строка» используется более чем в одной таблице, то лучше перейти от неименованных строк к именованным. В последней части листинга приведен пример создания таблицы part, в которой некоторые физические характеристики предмета хранятся в неименованной строке part-dimension. Тип данных «строка»(row) может содержать данные практически всех других типов, включая расширенные типы. В этом типе данных не могут содержаться данные типа serial (4- и 8-ми байтовые). С точки зрения разработчика приложений тип данных строка имеет как преимущества, так и недостатки. Рассмотрим преимущества. Во-первых, с точки зрения бизнеса этот тип данных интуитивно понятен. Например, если вы используете некоторые данные как одно целое, то и моделировать их так удобнее. С точки зрения приложения такой подход уменьшает количество SQL-операторов, необходимых для манипулирования отдельными частями логического элемента. С другой стороны, кода меньше, но он сложнее. Со стороны администратора тип данных «строка» требует умения предвидеть, поскольку данные этого типа нельзя преобразовать в другой тип (вы можете это сделать, например, для символьных и числовых типов), а можно только удалить и создать заново. В Листинге 2.3 приведен пример SQL-команд, выполняемых из dbaccess, для управления данными в таблице, скрипт создания которой приведен в Листинге 2.1 insert into student values (0, row(“John”,”Doe”)::name_t, row(“1234 Main Street”,””,”Anytown”,”TX”, “75022”):address_t,”Big Co.”); select * from student where name.lname matches “Doe”; student_id 1234 (?????) name row (‘John’,’Doe’) address row (‘1234 Main Street’,’’,’Anytown’,’TX’,’75022’) company Big Co. Для операции вставки необходимо сделать два уточнения:

Ключевое слово row показывает, что следующие за ним данные будут вставлены в элемент типа данных row.

Имя, указанное после данных, (в примере ::name_t), используется для преобразования данных в требуемый тип. Ниже мы подробно рассмотрим вопросы преобразования данных.

Второй запрос является примером выборки данных по фильтру, включающему элементы типа row. Обратите внимание на использование «точечной» записи для уточнения необходимых элементов. Если элемент row используется внутри другого типа данных, то используется «трехточечная» запись:

create row type name_t (fname varchar(20), lname varchar(20)); create row type address_t (street_1 varchar(20), street_2 varchar(20), city varchar(20), state char(2), zip char(9)); create row type studentinfo_t (name name_t, address address_t); create table student (student_id serial, name_address studentinfo_t, company varchar(30)); insert into student values (0, row (row(“John”,”Doe”)::name_t, row(“1234 Main Street”,””,”Anytown”,”TX”,”75022”)::address_t )::cust_t, ”Big Co” ); select * from student where name_address.name.lname matches “Doe”; student_id 1234 name_address row(row(‘John’,’Doe’), row(‘1234 Main Street,’ ‘,’Anytown’,’TX’,’75022’)) company Big Co Листинг 2.4. Доступ к элементам именованной строки Как я говорил выше, нельзя модифицировать определения типа данных row, их необходимо удалить и пересоздать. Для удаления определения именованной строки используется ключевое слово restrict. drop row type studentinfo_t restrict; Тип данных «Коллекция» На следующей ветви дерева расширенных типов находятся три разных типа «коллекция». Тип коллекция позволяет хранить несколько элементов одного типа данных в столбце. Чтобы понять общую идею такого типа данных, - вспомните о массиве. В коллекции можно хранить практически любой тип данных, включая расширенные типы. В коллекции не могут содержаться типы данных serial (4- и 8-ми байтовые), byte,text. Максимальный размер коллекции составляет 32 Кбайта, что ограничивает коллекцию в качестве хранилища BLOB-объектов. Коллекции обычно применяют тогда, когда элемент данных бесполезен без остальных элементов коллекции (например, в коллекции можно хранить список очков в гольфе, список задач и т.п.)

В IDS существует три типа коллекций: set, multiset, list. Они отличаются только поддержкой уникальности элемента коллекции, как показано в таблице 2.1.

Имя типа Описание set Гарантируется уникальность элемента коллекции, порядок не

определяется set {“apple”,”orange”,”grapefruit”,”plum”}

multiset Не гарантируется ни уникальность, ни порядок multiset {“apple”,”orange”,”grapefruit”,”apple”,”plum”,”grapefruit”}

list Гарантируется порядок, но не уникальность list {“apple”,”apple”,”grapefruit”,”grapefruit”,”orange”,”plum”} list {“apple”,”grapefruit”,”tangerine”,”apple”,”orange”,”plum”}

Таблица 2.1. Типы данных «коллекция» и их характеристики Как видно из описания списка, термин «порядок» не применим к элементам списка в смысле их типов (числовой, символьный), а только в смысле того, что порядок появления элементов соблюдается. Элементы списка нумеруются с единицы. Обратите внимание, что элементы списка указываются внутри фигурных скобок ({}). Коллекции не могут содержать в себе null-значений. Поэтому, если вы планируете использовать коллекцию, не забудьте в определении соответствующего столбца указать not null. Второй интересный факт состоит в том, что если попробовать вставить в set уже имеющееся в нем значение, то оно не будет вставлено и код ошибки тоже не будет сгенерирован. Прдолжая наш пример из прошлого раздела, давайте используем коллекцию для создания таблицы, в которой хранится информация о предметах. Код приведен в Листинге 2.5 create table class ( class_id serial, class_name varchar(6), description lvarchar, prereqs set(varchar(20) not null) ); insert into class values(300, “Performance and Tuning”, “Covers advanced information on tuning Informix Dynamic Server”, (set{“Relational Database Design”, ”Basic SQL Programming”}) ); select * from class where (“Advanced SQL Programming”) in prereqs; Листинг 2.5. операции с типом данных «коллекция» Первый оператор SQL используется для создания таблицы, а второй – для занесения в нее записи. Синтаксис похож на синтаксис использования именованной строки: вам необходимо определить тип коллекции, куда будут вставляться элементы. В операциях SQL с коллекциями можно использовать либо предикаты, либо ключевое слово in(как показано в третьем запросе Листинга 2.5). Если язык программирования поддерживает массивы, то «коллекции» можно складывать в переменные типа «массив». Если вы используете IBM Informix 4GL, то можете для хранения «коллекций» создать переменные типа set, multiset, list. Вернемся к нашему примеру и предположим, что в списке требований к курсу была допущена ошибка. Например, студенту, кроме вышеперечисленных курсов, необходимо

пройти еще «Advanced SQL programming». Вы не можете модифицировать одни или несколько элементов коллекции – необходимо переписать все значения. Это можно сделать или напрямую, или с использованием переменной (показано в Листинге 2.6) update class set prereqs= (set {“Relational Database Design”, “Advanced SQL Programming”, “Basic SQL Programming”} ) where class_id=300; update class set prereqs=set_char where class_id=300; (???????) Листинг 2.6. изменение переменной типа «коллекция» С точки зрения разработки структуры базы, коллекции дают возможность хранить записи типа «мастер-деталь» в одной таблице. Основные потребители такого функционала – финансовые, производственные, научные организации. Например, в одной большой торговой компании торговая информация за день хранится в коллекции, которая находится в столбце таблицы торговых дней. В промышленных организациях коллекции используются для хранения в них данных, получаемых с систем мониторинга. В коллекции можно хранить элементы заказа. Определенные пользователем типы. Давайте переместимся к самой правой ветке дерева расширенных типов и рассмотрим типы данных, определенные пользователем. Эти типы данных довольно контрастные – одни легко использовать, другие требуют больше внимания. Исключительные типы данных (distinct data types) Тип distinct получается из встроенного типа данных и является примером принципа наследования. Хотя этот тип данных и наследует все свойства базового типа, но имеет свое уникальное имя, которое отличает его от других, «подобных» типов. Сервер отделяет базовый тип и distinct-тип друг от друга и требует явного приведения типов. Поскольку distinct-тип отличается от встроенного типа, вы можете для этого типа создавать определенные пользователем процедуры, правила преобразования, и они не затронут базовый тип. В объектно-ориентированном программировании это называется перегрузка. Для иллюстрации использования distinct-типов предположим, что нам необходимо разработать модуль БД по продаже сувениров в Европе. Расчеты могут производится в долларах или евро. Таблица продаж имеет такой вид: create distinct type dollar as decimal; create distinct type euro as decimal; create table sales ( sku int, sales_date datetime year to second, us_sales dollar, euro_sales dollar ); В этом случае мы создали два типа distinct, наследующие характеристики типа данных decimal. Занесем в таблицу данные:

insert into sales values(1234,current,15.0::dollar,0::euro); insert into sales values(5678,current,0::dollar,75.0::euro); insert into sales values(1234,current,84.75::dollar,0::euro); Обратите внимание на использование двойного двоеточия (::) для преобразования данных в необходимый тип. В конце дня менеджер хочет узнать, на сколько денег было продано каждого товара. Он выполняет запрос: select sku,(sum(us_sales)+sum(euro_sales)) from sales where date(sales_date)=today group by 1; выполнение запроса завершится такой ошибкой: error: 674 - routine (plus) cannot be resolved Почему это произошло? С точки зрения менеджера обе суммы должны складываться, поскольку это обычные числа. Но с точки зрения сервера это разные типы данных, поэтому сервер не знает, как складывать типы данных euro и dollar. Из этого примера можно увидеть полезность distinct-типов: предупреждение логических ошибок вычислений и возможность определить тип данных, который соответствует характеру данных, которые в нем хранятся. С точки зрения логики некорректно суммировать деньги в разной валюте. Сначала необходимо преобразовать одну валюту к другой по соответствующему курсу. С точки зрения бизнеса удобно, чтобы наименование типа данных несло информацию о том, что хранится в столбце этого типа данных. Вернемся к исходной задаче. Нормально желать, что менеджер получит свой отчет по ежедневным продажам без необходимости писать неестественный SQL-запрос. Этого можно достичь несколькими путями. Сейчас мы обсудим первый метод, а в разделе о преобразовании данных – второй. Базовой возможностью distinct-типов является наследование, поэтому когда ты определяем тип dollar, используя в качестве основы для него тип decimal, то тип dollar наследует функции для манипулирования с decimal (sum(),plus() и т.д.). Зная это, нам необходимо преобразовать один из типов (dollar или euro) в другой. Для этого можно создать хранимую процедуру или определенную пользователем функцию, которая будет преобразовывать евро в доллары или доллары в евро. Этот подход продемонстрирован в Листинге 2.7 create function dlr_to_euro(parm1 dollar) returning euro specific usd_to_euro; return (parm1::decimal*0.804)::euro; end function; create function euro_to_usdlr(parm1 euro) returning dollar specific euro_to_usd; return (parm1::decimal/1.346)::dollar; end function;

select sku,(sum(us_sales)+sum(euro_to_usdlr(euro_sales))::dollar) from sales where date(sales_date)=today group by 1; Листинг 2.7. Использование определенных пользователем функций для работы с Типами данных distinct В реальном приложении необходимо курс пересчета получать в реальном времени, а не жестко фиксировать. Непрозрачные типы данных (Opaque data types) Тип данных opaque – это заменить(wildcard) других типов данных. Если типов данных сервера недостаточно для моделирования и хранения ваших данных, вы можете создать свой собственный opaque(непрозрачный) тип данных. Эти типы данных похожи на простые BLOB-ы. Сервер БД не имеет представления о структуре таких данных и как ими манипулировать. С точки зрения сервера, это просто «значение», которое не может быть разделено на составляющие. Из этого следует вывод, что вы должны определить характеристики типа данных и написать процедуры работы с ним. Для определения типа данных используются структуры С или Java, а манипулирование opaque-данными производится с помощью процедур, написанных на С или Java и зарегистрированных в сервере БД. Opaque-типы данных могут иметь фиксированный или переменный размер (с ограниченным максимальным размером). Максимальный размер этого типа данных составляет 32 Кбайта. Если вам необходимо, чтобы тип данных имел больший размер, - используйте смарт-BLOBы. Данные opaque-типа должны быть отформатированы в соответствии с требованиями ОС, которая управляет сервером. При создании opaque-типа данных необходимо определить границу выравнивания (alignment boundary). В таблице 2.2 приведены возможные значения границы выравнивания.

Таблица 2.2. Границы выравнивания типа данных opaque Граница выравнивания

Описание

1 однобайтовые структуры

2 Структуры, похожие(resemble) на unsigned small integer

3 Структуры, похожие(resemble) на unsigned integer

4 Структуры, похожие(resemble) на тип данных double data

По умолчанию используется граница выравнивания 4 байта. В отличие от других типов данных, которые получаются целиком или частями, определенная пользователем функция получает указатель на данные opaque-типа. Это похоже на работу с BLOB-объектами, когда в столбце хранится не BLOB, а указатель на его расположение в BLOB-пространстве. Исключение из этого правила такое – тип данных имеет размер 4 байта и создан с использованием флага PASSEDBYVALUE. При подготовке к созданию типа opaque, необходимо сначала создать и зарегистрировать определенные пользователем функции (UDR) для ввода/вывода, удаления данных этого типа ,манипулирования ими (сложение, вычитание и другие

применимые операции), агрегирования (если применимо), расчета статистики для оптимизатора IDS и т.д. В листинге 2.8. приведен пример создания opaque-типов create function mytype_in (lvarchar) returning my_type with (not variant); external name “/funcs/my_type.so” language C end function; create opaque type my_type (internallength=variable,maxlen=1024,aligment=1,cannothash); Листинг 2.8. пример создания типов opaque Преобразование типов (casting) Надеюсь, вы убедились, что объектно-ориентированные возможности IDS полезны. Они могут прекрасно подходить для построения модели данных, но их применение в реальных приложениях – это совсем другая история. Если типы данных не могут использоваться совместно друг с другом, то лучше их не использовать. Для решения задач преобразования данных друг в друга используется объектно-ориентированная возможность, которая называется преобразование типов (casting). Преобразование типов преобразует данные одного типа к данным другого типа так, чтобы над ними можно было проводить необходимые операции. В реляционном сервере вы тоже используете преобразование типов, хотя, возможно, и не знаете об этом. Именно возможности преобразования типов позволяют вставить данные integer в столбец decimal или числовой тип данных в столбец character. Если преобразование типов невозможно, например, нельзя преобразовать символьный тип данных в числовой, сервер вернет ошибку преобразования типов. Использование преобразования типов данных не является обязательным. Преобразования типов могут быть перегружены. Вы можете создавать правила преобразования типов для всех типов данных, кроме коллекций, BLOBов и неименованных строк. Давайте рассмотрим два типа преобразования: явное и неявное. Неявное преобразование типов. Неявное преобразование типов - одно из тех действий, которое выполняется при соединении между собой неодинаковых типов, например, при попытке сложить доллары с евро. С неявным преобразованием надо быть осторожным, поскольку оно может привести к получению неправильных результатов. Выше мы рассматривали пример с продажей сувениров за доллары и евро. Первая попытка получить отчет по продажам за день закончилась неудачно из-за ошибки преобразования типов. Альтернативное решение – приведение типов (см. Листинг 2.9) select sum(us_sales)+sum(euro_sales) from sales where date(sales_date)=today; #674 Routine(plus) cannot be resolved; create implicit cast (euro as dollar); select sum(us_sales)+sum(euro_sales) from sales where date(sales_date)=today;

(expression) 120.00 Листинг 2.9. Использование преобразования типов. Выражение create cast предписывает серверу обрабатывать в математических операциях тип euro как тип dollar. Теперь SQL-запрос будет выполнен без ошибки. Проблема решена? К сожалению нет: с математической точки зрения вес правильно (50+70=120), но 70 евро не соответствуют 70 долларам. Чтобы запрос возвращал правильные данные нам необходимо обеспечить перевод евро в доллары по соответствующему курсу с помощью функции, описанной выше в этом разделе. drop cast (euro as dollar); create implicit cast (euro as dollar with euro_to_usdlr); select sum(us_sales)+sum(euro_sales) from sales where date(sales_date)=today; (expression) 80.00 Обратите внимание, что сначала сумма продаж в евро передается в функцию euro_to_usdlr. Полученный из функции результат трактуется как число типа данных dollar, и перегруженная функция plus может сложить два значения типа dollar. Правильно созданные неявные преобразования могут помочь не менять клиентское приложение при изменении объектов БД. Явные преобразования типов. Сила неявного преобразования типов – немедленность и бесшумность – одновременно является и слабостью. Иногда один тип данных может быть однозначно преобразован в несколько типов данных и необходимо динамически определить подходящий тип. В этом случае используется явное преобразование типов. Вы могли видеть явное преобразование типов в предыдущих примерах, хотя там явно не говорилось об этом. Два нижеприведенных примера показывают, как явно привести значение my_param к типу данных new_type my_param::new_type my_param cast as new_type В другой части программы может оказаться необходимым преобразовать значение my_param к типу данных really_new_type. Преобразование типов «по требованию» - отличительная особенность явного преобразования типов данных. Как и в случае неявного преобразования, вы можете предопределить правила явных преобразований на уровне экземпляра, и не будет необходимости включать правила преобразования типов в приложение. Давайте, например, предположим, что нам необходимо переделать наш модуль продажи сувениров, поскольку компания по продаже сувениров была куплена кем-то. Новые владельцы хотят видеть отчет по продажам в долларах, а продажи в евро пересчитать в японские иены. Чтобы удовлетворить последнее пожелание правила неявного преобразования удаляются и создается distinct-тип yen. Рассмотрим теперь Листинг 2.10

select sum(us_sales)+sum(euro) from sales where date(sales_date)=today; #674 Routine (plus) cannot be resolved execute my_function(in_1) returning yen select sum(euro_sales)/yen_value from … #674 Routine (divide) cannot be resolved create explicit cast (euro as dollar) create explicit cast (euro as yen) select sum(us_sales)+sum(euro) from sales where date(sales_date)=today; #674 Routine (plus) cannot be resolved execute my_function(in_1) returning yen select sum(euro_sales)/yen_value from … #674 Routine (divide) cannot be resolved Листинг 2.10 Функциональные отличия в явных преобразованиях. Почему ничего не работает? Созданы все правила для преобразования типов. Почему не выполняется преобразование? Явные преобразования, в независимости от того, как они определены, не вызываются сервером БД автоматически. Необходимое явное преобразование должно быть вызвано. Смотрите пример Листинг 2.11 drop cast (euro as dollar); drop cast(euro as yen); select sum(us_sales)+sum(euro_sales)::dollar from sales where date(sales_date)=today; (expression) 120.00 create explicit cast (euro as dollar with euro_to_usdlr); create explicit cast (euro as yen with euro_to_yen); select sum(us_sales)+sum(euro_sales)::dollar from sales where date(sales_date)=today; (expression) 80.00 execute my_function(in_1) returning yen select euro_sales cast as yen/yen_value from … (expression) 2400.65 Листинг 2.11 Использование явного преобразования типов. Первые два выражения удаляют существующие преобразования типа euro. В следующем выражении сумма продаж в евро преобразуется к типу данных dollar, а затем выполняется суммирование двух долларовых величин. К сожалению, результат этой операции

неправилен, поскольку не выполняется «обмен валюты по курсу». Следующие выражения используются для создания явных преобразований типов с учетом курса обмена. Теперь данные euro_sales могут быть пересчитаны в евро или доллары с минимальными изменениями в клиентском приложении. Сервер БД распознает выражение euro_sales cast as yen и вернет правильный результат. Определенные пользователем функции и агрегаты. Определенные пользователем функции и определенные пользователем агрегаты (UDA – user-defined aggregates) – это расширения программирования на стороне сервера. Они доступны в Informix уже много лет. В ранних версиях эти средства программирования были ограничены хранимыми процедурами, написанными на языке SPL (stored procedure language – язык написания хранимых процедур). IDS 11 также поддерживает SPL. Принципы написания процедур не изменились – после создания процедуры оптимизатор разбирает ее и хранит план выполнения в системных таблицах экземпляра. В IDS 11 SPL был расширен – добавлены циклы, метки циклов, выход из цикла и выражение goto. Начиная с версии Informix Dynamic Server 9.1, можно писать «внешние» процедуры, которые регистрируются в экземпляре и выполняются как хранимые процедуры или другие части двоичного кода сервера. Такие внешние функции могут быть написаны на С или Java и выполнять более сложную обработку данных, чем хранимые процедуры на SPL. В документации Informix Dynamic Server определенные пользователем процедуры и определенные пользователем функции иногда объединяются под названием «определенные пользователем агрегаты». С точки зрения конечного приложения процедуры и функции различаются по количеству возвращаемых параметров. Для обозначения процедур и функций мы будем использовать общий термин UDR. UDR, написанные на Java, должны быть скомпилированы в jar. После регистрации функции в экземпляре содержимое jar-файла копируется в smart BLOB-пространство и выполняется с использованием HotSpot Java Virtual Machine (JVM). UDR, написанные на С, должны быть скомпилированы в объектный вид (filename.so) и помещены в каталог, путь к которому определен в конфигурационном параметре DB_LIBRARY_PATH. UDR должны быть написаны максимально кратко и точно, Если тратится много времени на выполнение кода UDR, то производительность экземпляра может существенно снизиться. При создании UDR обязательно необходимо предусмотреть обработку ошибок, используя конструкцию raise exception и другие встроенные функции. Поскольку UDR могут перегружать другие UDR и/или встроенные функции, хорошей практикой является использование при определении UDR специфичного имени или псевдонима. Например, можно создать такие перегруженные UDR с разными сигнатурами: create function comp_val(in_1 dollar,in_2 aus_dollar) … create function comp_val(in_1 aus_dollar,in_2 euro) … create function comp_val(in_1 euro, in_2 aus_dollar) … Сигнатура UDR – это комбинация имени функции/процедуры и ее параметров. Когда происходи вызов UDR, сервер определяет типы передаваемых параметров и решает,

какую из перегруженных UDR выполнять. Использование UDR предполагает или ее вызов по полной сигнатуре, или, если вы такой же ленивец, как я, через псевдоним (alias): create function comp_val(euro,aus_dollar) returning aus_dollar, specific euro_to_ausdlr . . Удалить функцию можно двумя способами: drop function plus(euro,aus_dollar); drop specific function euro_to_ausdlr; Хотя примеры выполняют одно действие, использование псевдонима позволяет избежать длительного стучания по клавиатуре, особенно если у функции длинная сигнатура. Некорректная UDR может привести к аварийной остановке сервера(crash). Для уменьшения этой опасности IDS предоставляет возможность создания определенных пользователем виртуальных процессоров(UDVP – user-defined virtual processor). После создания одного или нескольких таких процессоров можно указать серверу выполнять UDR только на этих процессорах, что значительно уменьшит вероятность аварийной остановки сервера. В Листинге 2.12 приведен пример: VPCLASS finance_vp, num=2 # vp for finance UDRs (ВП для финансовых UDR) или onmode –p +2 finance_vp create function comp_val(dollar,aus_dollar) returning aus_dollar specific dollar with class=”finance_vp” external_name ‘/usr/Informix/shared_lib/comp_functions.so’ language C not variant end function; Листинг 2.12 Использование определенных пользователем ВП для защиты от криво написанных UDR В этом примере показаны два метода создания UDVP. Первый требует изменения файла $ONCONFIG и перезапуска экземпляра, а второй выполняется, когда экземпляр находится в режиме он-лайн и обрабатывает данные. После создания UDVP создается и регистрируется функция, причем при регистрации указывается, что функция выполняется только на виртуальном процессоре finance_vp. Определенные пользователем виртуальные процессоры находятся в отдельном от системных ВП адресном пространстве. Если UDR написана некорректно, ее негативное влияние ограничится только UDVP и не затронет ядро сервера. По умолчанию UDR являются однопоточными, но они могут быть распараллелены при выполнении нескольких условий, включая следующие:

Включено распараллеливание PDQPRIORITY>1 При регистрации UDR указано ключевое слово parallelizable UDR на С и Java используют вызовы потокобезопасных API Parallel Database

Query(PDQ) Сложные типы данных не используются в качестве входных и выходных

параметров Сканы будут выполняться в нескольких партициях таблицы (data scans will search

multiple table partitions) UDR не являются функциями-итераторами, а выполняются один раз и

завершаются Если вы ошиблись при регистрации UDR, ошибку можно исправить используя SQL-команду alter function: alter function bigger (int, int) with (add parallelizable, add class=”math_vps”); Для мониторинга работы UDR используется утилита onstat и другие. Определенные пользователем агрегаты (UDA)

Это специальные UDR для выполнения агрегации, которая не поддерживается встроенными функциями сервера. Как вы знаете Informix поддерживает sum(), divide(), mod() и другие математические функции для встроенных типов данных. Эти функции не работают для определенных пользователем типов данных, их может оказаться недостаточно для хитрого агрегирования или в случае, когда необходимо агрегирование данных встроенных и расширенных типов. Примером определенного пользователем агрегата может быть последовательность Фибоначчи. Ее значения получаются так: два соседних элемента складываются и образуют третий, затем третий элемент складывается со вторым и получается четвертый, четвертый суммируется с третьим, и получается пятый и т.д: 0,1,2,3,5,8,13,21,34,55,89,144… Последовательность Фибоначчи Например, для каких то целей может потребоваться вычислить члены последовательности Фибоначчи, имея начальное значение и количество итераций. Именно в таком случае целесообразно использовать UDA. Создание UDA сложнее, чем создание UDR. Обычно UDA являются итеративными и состоят из четырех модулей, которые выполняют следующие функции:

Инициализация – выделение и инициализация ресурсов сервера для использования их в функции

Итерация – увеличение числа строк и выполнение необходимых математических расчетов.

Комбинация – прибавление вычисленного значения к возвращаемому из функции результату.

Финализация - возвращение значений и освобождение ресурсов сервера.

Обычно UDA пишут на С или Java, особенно если в вычислениях используются научные и/или статистические расчеты и для получения новых значений используются внешние процедуры. Расчеты такого типа сложно писать на SPL. Функциональные индексы. Индексы -это указатели на месторасположения данных. Informix может создавать индексы по одному или нескольким столбцам. В реляционном сервере БД индексы создаются на основе значений, находящихся в одном или нескольких столбцах. Однако, не все операции с данными основаны на абсолютных значениях этих данных. Некоторые данные лучше представлять в виде отношения, процентного значения и т.д. В IDS в таком случае вы можете использовать функциональный индекс. Предположим, что необходимо работать с данными, которые представляют собой взвешенное отношение данных из трех столбцов. Тогда можно создать индекс по этому отношению таким образом: написать, скомпилировать и зарегистрировать UDR, вычисляющую это отношение. Затем можно создать индекс: create index ix_w8ed_ratio(build_ratio(col3,col5,col10))

Функциональные индексы также используются для создания вторичных методов доступа(secondary access methods) или алгоритмов сравнения величин. Большинство индексов обрабатываются одним из двух стандартных алгоритмов:

В-дерево (B-tree) – данные равны, больше чем, меньше чем, меньше или равны, больше или равны

R-дерево(R-tree) – данные состоят из одного из двух элементов:

1. многоразмерные(multidimensional) – данные в нескольких измерениях, например, географические (широта, долгота, высота), комбинация нескольких независимых элементов в многоразмерное представление; например, можно создать функциональный индекс одежды на основе ее цвета, материала, из которого она изготовлена, производителя, дизайнера и т.д.

2. диапазонные. Например, диапазон широт между двумя граничными значениями, диапазон времени между двумя событиями.

Если этих методов доступа недостаточно или они не обеспечивают необходимой производительности, вы можете создать свою собственную схему индексирования и зарегистрировать ее в экземпляре. Именно так поступила компания-партнер Coppereye LTD. Ее сотрудники разработали новый метод индексирования реляционных данных, который значительно уменьшает время построения индекса без снижения его производительности. В Coppereye был создан DataBlade, который при установке перегружает многие встроенные функции работы с индексами. Для использования алгоритма Coppereye, DBA при создании индекса должен указать алгоритм его обработки

create index ix_myindexon table_a(col2,col3) using coppereye;

DataBlade-ы, Bladelet-ы и прочие дополнения.

Как вы смогли убедиться, объектная функциональность IDS дает вам возможность хранить и обрабатывать данные путем, который максимально подходит вашему бизнес-окружению. Некоторые вендоры используют эти возможности для создания наборов UDR, сообщений об ошибках, алгоритмов приведения типов. Эти наборы носят наименование DataBlade-ов. Они предназначены для решения широкого круга задач: выше я уже упоминал о схеме индексирования Coppereye, также есть DataBlade-ы по обработке биометрических данных, аудио и видео и так далее. Enterprise редакция IDS 11 включает в себя лицензию на использование нескольких DataBlade-ов. Более мелкие функциональные расширения IDS называются Bladelet-ами и могут быть бесплатно загружены с веб-сайтов International Informix User’s Group (IIUG) и IBM developerWorks (http://www.iiug.org, http://www.ibm.com/developerworks). Полсе регистрации Bladelet-а или DataBlade-а его функциональность становится доступна через SQL, SPL или вызовы API. DataBlade-ы и Bladelet-ы устанавливаются на уровне экземпляра, обычно в каталог $INFORMIXDIR/extend, и регистрируются в каждой базе данных, где требуется использовать их функциональность. Определение функций, типов данных и других компонентов DataBlade-а или Bladelet-a хранится в системных таблицах БД(sysprocbody) . При удалении Bladelet-а из БД данные о Bladelet-е удаляются из этой таблицы. Заключение На протяжении многих лет сервера БД были критическими элементами инфраструктуры ИТ. При выборе сервера основное влияние уделялось скорости его работы и функциональности. Сегодня ситуация изменилась. Я не хочу сказать, что сервера БД перестали быть важными, но фокус находится на приложениях и языках разработки. Эти элементы привлекают пользователей флэш-графикой, громкими названиями и обещаниями поменять инфраструктуру ИТ за ночь, естественно, в лучшую сторону. Сервера БД рассматриваются как что-то скучное м пригодное только для хранения и выдачи данных по запросу, написанному на модном языке. С точки зрения разработчика необходимо использовать только самый базовый функционал сервера, поскольку этот разработчик может перейти на другой язык (который обещает спасти мир), а тот не будет поддерживать специфичного функционала сервера, а только базовые конструкции select,insert,update,delete. По моему мнению, это в корне неправильный подход. Сервера БД отличаются, и отличаются значительно. IDS позиционируется на рынке как уникальный сервер, объединяющий скорость обработки данных с расширяемостью, позволяющей обрабатывать данные с учетом бизнес-логики. Определенные пользователем типы данных и функции, Bladelet-ы и DataBlade-ы могут быть добавлены к серверу для расширения его функционала. Используя эти возможности, вы можете сократить время разработки приложений. Использование этих возможностей IDS предполагает, что вы измените свои подходы к моделированию и разработке баз данных. Например, я считаю, что необходимо широкого использовать distinct-типы данных. Это практика поможет предупредить ошибки в вычислениях. Сейчас вы готовы к более подробному рассмотрению установки и запуска экземпляра IDS. В части 3 мы рассмотрим вопросы, которые необходимо решить перед инициализацией экземпляра. Разговор во многом будет общий, поскольку в этой сфере очень мало четких правил. У каждой установки свои уникальные условия и предъявляемые к ней требования, которые определяют, как экземпляр создается и управляется.

Часть 3. Подготовка к инициализации В этой части:

общие вопросы проектирования базы данных вопросы конфигурации жестких дисков введение в стратегии архивирования установка необходимых переменных окружения подготовка к резидентности

Эта часть охватывает широкий круг вопросов, на которые необходимо дать ответы перед инициализацией экземпляра Informix и созданием базы данных. Мы обсудим вопросы проектирования базы данных, выбора размера таблицы, конфигурирования жестких дисков, стратегии архивирования, переменные окружения. После прочтения раздела вы будете готовы подготовить вычислительную среду для установки Informix Dynamic Server. Большинство вопросов, которые мы будем обсуждать, очень субъективны и для многих из них нет четких рекомендаций. Ваши приложения и базы во многом уникальны и что подходит для одной может быть абсолютно бесполезно для другой. Именно вам, администратору БД, выбирать, что лучше всего подойдет в вашей ситуации. Администрирование сервера БД – сплав науки и искусства. Производительность сервера во многом зависит от способности администратора правильно настроить экземпляр. Нужно сказать, что IDS с каждым выпуском становится более автоматизированным и самонастраиваемым. Хотя сервера БД никогда не смогут работать полностью без администратора, IDS старается максимально приблизиться к этой цели. Заключительное слово перед тем, как мы начнем: перед установкой IDS прочтите документацию на диске, которая содержит замечания по выпуску, а также рекомендации по настройке ОС для запуска IDS. В последнем релизе для Linux, UNIX, MacOS документация, в отличие от предыдущих версий, доступна без установки сервера. После распаковки дистрибутива, она доступна в каталоге Server/doc. После инсталляции документация доступна в каталоге $INFORMIXDIR/release/en_us/0333 для варианта США/английский язык. В случае другого языка или страны подкаталог в каталоге release будет отличаться. Логические вопросы проектирования базы данных. Перед установкой нового экземпляра рекомендуется потратить достаточно времени для проектирования окружения экземпляра и баз данных, которыми будет управлять экземпляр. Необходимо представлять себе требуемую общую производительность, размер базы данных и таблиц, взаимодействие таблиц, как будет производится фрагментирование таблиц и индексов, каково допустимое время восстановления. Мой опыт подсказывает, что правильно учесть все необходимое с первого раза практически невозможно. Давайте рассмотрим проектирование базы данных. Нужно знать не только, сколько таблиц будет в базе данных, но и как эти таблицы будут взаимодействовать между собой. Также неплохо знать, какой ожидается рост размеров таблиц, поскольку от этого будет зависеть проектирование дисковой структуры. От предполагаемого размера таблиц зависит их размещение в db-пространстве и схема фрагментирования. В свою очередь, от решения этого вопроса зависит количество создаваемых db-пространств, количесвто необходимых жестких дисков и методы защиты от их сбоя. Второй фактор, влияющий на проектирование и размещение таблиц, - характер приложений, которые будут взаимодействовать с базой данных. Будут они выполнять интенсивное обновление или чтение? Какой характер самых популярных запросов? Будут

ли пользователи иметь доступ к базе данных с помощью инструментальных средств? Если да, то как защитить таблицы и строки? Лучший путь учесть все факторы и условия – это построить функциональный план разработки всего приложения. Эта задача включает в себя анализ требований к производительности и различных существующих ограничений. Для начала надо ответить на такие вопросы:

какую информацию должны видеть конечные пользователи и как она будет отображаться

какие типы данных будут храниться в базе данных как приложение будет получать данные как данные будут вводиться, изменяться и удаляться. Когда и как это будет

происходить какой отрезок времени считается приемлемым для выполнения операции в базе

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

Некоторые люди называют этот процесс «интим с данными». Как администратор БД вы должны знать ответы на эти вопросы, чтобы при необходимости помочь разработчикам и администрировать сторонние приложения. При покупке стороннего ПО администратор должен представлять ответы на вышеперечисленные вопросы. Как и у любого другого разработчика, у вендора есть сильные и слабые стороны. Сильная сторона – возможности приложения (иначе бы вы его не опкупали). Однако у вендора не всегда есть возможность создать окружение БД, наиболее подходящее для приложения. Вы можете улучшить скорость работы приложения путем получения максимума информации о дизайне базы данных и о том, как приложение работает с этой базой данных. После того, как приложение установлено, посмотрите размер, месторасположение и количество db-пространств. В зависимости от ваших аппаратных ресурсов мы можете пересмотреть местоположение таблиц и схему их фрагментирования для достижения большей производительности. Кроме того, стоит мониторить проводимые в БД операции. Настройка производительности может проводиться на уровне экземпляра или SQL-запросов к БД. Версии IDS 10 и старше позволяют регистрировать директивы оптимизатору SQL для запросов, к которым у вас нет доступа для их модификации. При выполнении запроса сервер учитывает эти директивы. IDS 11 включает в себя возможность определять самые медленные и дорогостоящие запросы, поэтому вы сразу можете увидеть, над чем необходимо работать. Короче говоря, не прислушивайтесь только к советам вендора по установке и настройке приложения. На основе знаний о взаимосвязи таблиц, размерах их возможного роста вы можете принять решение о дисковой конфигурации сервера. Логический дизайн базы данных – основа проектирования базы данных на физическом уровне: где размещать таблицы, какую избрать схему фрагментирования. Знание того, как приложение работает с БД позволит вам определить режим ведения логического журнала и его архивирования. При инициализации экземпляра также могут быть установлены предварительные размеры разделяемой памяти и других конфигурационных параметров. Вычисление размеров таблиц. При использовании неформатированного дискового раздела (сырое пространство) на Linux/UNIX сервер Informix выделяет дисковое пространство для таблиц путем создания на этом разделе непрерывных секций для db-пространств. Размер db-пространств

указывает администратор БД. Такой подход ведет к уменьшению количества движений головок дисков и времени чтения таблиц. Вместо того, чтобы обращаться к различным частям диска, головка движется в непрерывных разделах диска. Одним из следствий является повышение производительности. Если для хранения таблицы требуется больше места, сервер попробует выделить место так близко, как это возможно, и выполнит логическое объединение пространств, занятых этой таблицей. Иногда сервер может выделить пространство в смежной с таблицей области диска: оба пространства для таблицы образуют непрерывную область. Это ведет к повышению производительности чтения. В db-пространствах, где содержится более одной таблицы, не всегда возможно выделить для таблицы дополнительное смежное пространство, что приводит к пересечению таблиц. На рисунке 3.1 приведена графическая иллюстрация.

Рисунок 3.1. Пересечение таблиц в db-пространстве Как можно себе представить, через некоторое время части таблицы – табличные экстенты (table extents) – могут оказаться распределенными по всему db-пространству. В этом случае сервер БД должен создавать указатели на размещение частей таблицы в db-пространстве, следовательно, часть ресурсов ЦП тратиться на обслуживание таких списков-указателей. Кроме того, снижается производительность ввода/вывода, поскольку время тратится на перемещение читающей головки по всему диску. Для систем, где db-пространства размещаются на форматированных файловых системах (в выделенных файлах), вышеприведенные размышления не полностью применимы, поскольку вы не можете контролировать, в какую часть плоского файла, где расположен чанк и/или db-пространство, система будет записывать блок данных. Будьте уверены, что блоки данных будут записаны не строго последовательно, и будет наличествовать пересечение таблиц. Это повлечет снижение производительности дискового ввода/вывода, но преимущества размещения db-пространств в выделенных файлах перекрывают этот недостаток. При использовании выделенных файлов, операционная система управляет указателями на части db-пространства, хотя это не полностью снимает с сервера БД задачи управления месторасположением данных: сервер не занимается обслуживанием физических ссылок, но продолжает заниматься обслуживанием логических ссылок. Такая работа сервера БД может понизить эффективность использования ЦП в случае, если количество экстентов таблицы достигает большого числа. Вы можете повлиять на пересечение таблиц путем вычисления того, сколько пространства необходимо выделить для таблицы при ее создании и после некоторого

времени. При работе с ранними версиями IDS я использовал следующие правила для вычисления размеров таблиц: - начинаем с начального количества строк в таблице и прибавляем к ним ожидаемое

количество строк за следующие шесть месяцев. - полученное количество строк используем для расчета размера начального экстента

таблицы - ожидаемое количество строк за следующие шесть месяцев используем для расчета

размера следующего экстента. При расчете размера следующего экстента я делил не на 7, как советует документация, а на 6. Хотя это и приводит к увеличению размера экстента, но зато уменьшается количество экстентов в таблице. Я рекомендую использовать именно 6-ти месячный период, поскольку, во-первых, у вас будет достаточно времени для конфигурирования, а во-вторых, на протяжении этого времени вы сможете собрать более надежную статистику. Другое преимущество этого периода состоит в том, что некоторые таблицы растут быстрее, чем планировалось, и, поскольку вы выбрали размер экстента больше, то будете иметь и больше времени для пересмотра базы данных. В результате, таблица не начнет быстро размазываться по разным экстентам. В критической ситуации вы можете переместить таблицу в большее db-пространство. Такая же стратегия применяется и наши дни, хотя она и усложняется в том случае, если части таблицы размещены в разных db-пространствах или если индексы таблицы находятся в другомdb-пространстве. Используя приложение (или его версию в формате PDF с сайта поддержки книги), вы можете рассчитать размер таблицы в случае, когда не используется фрагментация таблицы. Если вы используете фрагментирование таблицы или размещение индексов таблицы в другом db-пространстве, то необходимо использовать другой подход для вычисления размера таблицы. Давайте кратко обсудим фрагментирование таблиц (подробно смотрите часть 6). Фрагментирование таблицы – возможность разместить части таблицы, в зависимости от некоторого условия, в различных db-пространствах. Для фрагментирования таблиц может использоваться два алгоритма. Алгоритм round-robin используется для равномерного размещения строк таблицы по всем ее фрагментам. Фрагментирование по выражению используется для точного указания db-пространства, в которое будет помещена строка таблицы. В случае использования фрагментирования по выражению при изменении столбца, который участвует в выражении фрагментирования, строка будет перемещена в соответствующее db-пространство. Использование фрагментирования по выражению может существенно повысить производительность системы. Возможность фрагментировать индексы означает, что:

индексы могут размещаться в том же db-пространстве (db-пространствах), что и таблица (индекс «прикреплен»)

индексы могут быть «полуоткрепленными» (semidetached) быть полностью отдельными и размещаться в других db-пространствах. В этом

случае используется логическое выражение, как и для фрагментирования таблиц Полуоткрепленный индекс имеет схему фрагментирования, которая включает в себя и то db-пространство, где была создана таблица, к которой он относится. Отдельный индекс находится в db-пространстве, отличном от db-пространства таблицы. При создании схемы фрагментирования индексов вы можете использовать комбинации и значения индексных ключей, но для индексов нельзя указать размер экстента. При вычислении размера экстента фрагментированных таблиц примите во внимание, что вы можете указать только одно множество размеров экстентов для таблицы. Для всех фрагментов таблицы, вне зависимости от схемы фрагментирования, начальный размер

экстента будет одинаковым. Когда для фрагмента таблицы требуется дополнительное место, сервер БД пробует выделить дисковое пространство, размер которого указан в параметре next size. Если используется схема фрагментирования round-robin, то все дополнительное пространство будет выделено для всех фрагментов таблицы одновременно. Такой подход имеет смысл, поскольку все фрагменты таблицы хранят одинаковый объем данных. Поэтому, когда вы рассчитываете размер экстента для таблицы, фрагментированной по алгоритму round-robin, используйте методику расчета для нефрагментированной таблицы. После получения размера начального и следующего экстента, разделите эти размеры на число фрагментов, которые вы планируете использовать. Если используется алгоритм фрагментирования round-robin, не забудьте перенести индексы таблицы в другое db-пространство. В Части 6 я объясню, почему это так важно. Если вы используете фрагментирование по выражению, то дополнительное место для фрагмента таблицы будет выделяться только тогда, когда он полностью заполнен. При фрагментировании таблицы по выражению некоторые фрагменты таблицы могут иметь размер больший, чем другие. При выборе размера следующего экстента таблицы вы можете посмотреть только на размер самых больших фрагментов таблицы и выбрать большой размер экстента. Но большой размер экстента может переполнить db-пространство, если этот экстент понадобится для маленького используемого редко фрагмента таблицы. В этом случае большая часть пространства просто пропадет. Именно по этой причине рекомендуется помещать большие фрагменты таблицы в отдельные db-пространства и использовать небольшое значение параметра next size. Для менее часто используемых фрагментов таблиц будут выделяться экстенты меньшего размера. Хотя при таком подходе для часто используемых фрагментов таблицы будет выделяться больше экстентов, но поскольку эти фрагменты хранятся в отдельных db-пространствах, явления пересечения экстентов для этих фрагментов не будет. Как рассчитать размер экстента для фрагментированной таблицы? Большие по размеру фрагменты необходимо разместить в отдельных db-пространствах, где нет других таблиц; маленькие фрагменты можно поместить в db-пространство с другими таблицами. Для выбора размера экстента используйте ожидаемое количество строк для самого маленького фрагмента таблицы. Еще одно замечание о фрагментировании по выражению. Необходимо принимать во внимание количество доступных дисков и его возможное противоречие со схемой фрагментирования, которая базируется только на бизнес-требованиях. Решение о фрагментировании индексов принимается на основе требований к приложению. OLAP-приложения, выполняющие последовательное сканирование таблицы, менее чувствительны к индексам, чем OLTP-приложения. Если индексы размещаются в одном или нескольких db-пространствах, сервер БД автоматически вычисляет размер экстентов для этих индексов. Размер экстента для индекса вычисляется с учетом размера экстента соответствующей таблицы и размера индексного ключа. Учтите, что при фрагментировании индекса, размер индексной строки увеличивается на 4 байта на каждый ключ. Вопросы, связанные с жесткими дисками. Один из первых вопросов, который я задаю перед началом новой инсталляции Informix или изменением в работающей системе, это «как база данных распределена по дискам». Используется ли зеркалирование средствами ОС или сервера, применяется ли RAID- массив или диски просто подключены к различным SCSI-контроллерам. Это совсем не бессмысленный вопрос. Например, массивы хранения (storage arrays) могут подключаться

к серверу напрямую или через сеть, могут быть сконфигурированы с поддержкой аппаратного зеркалирования или без нее. Не нужно забывать о возможности создать программный RAID-массив средствами ОС или сторонними программами. Все эти варианты конфигурирования жестких дисков могут повлиять на производительность и надежность работы IDS. в зависимости от требований к производительности и надежности системы вы можете выбрать ту или иную конфигурацию жестких дисков. Здесь нет одного готового ответа на все случаи жизни, но есть несколько определяющих правил. Первое правило. Вне зависимости от конфигурации дисков, где размещены чанки и db-пространства, диски, на которых находятся корневое db-пространство, физический и логический журналы, должны быть тем или иным образом защищены от аппаратного сбоя (можно использовать зеркалирование на уровне сервера БД, программный или аппаратный RAID). Ниже мы обсудим различные схемы конфигурирования жестких дисков. Зеркалирование Программное зеркалирование данных – ваш первый выбор; оно обеспечивается Informix Dynamic Server самостоятельно. Вы можете зеркалировать чанки и db-пространства экземпляра. Хотя зеркала функционируют асинхронно, но сервер БД ждет сигнала завершения записи и от зеркала, и от первичного диска. Такое поведение сервера может снизить производительность. Использование зеркалирования Informix имеет два недостатка. Первый – снижение скорости работы экземпляра. Операции записи в этом случае контролируются центральным процессором и виртуальными процессорами асинхронного ввода/вывода (AIO VPs). Эти задачи должны быть скоординированы с другими, которые выполняются этими ВП. В предыдущих версиях IDS ВП асинхронного ввода/вывода определялись статически, и если эти процессоры были заняты, процедуры записи зеркальных данных должны были ждать освобождения ВП. Начиная с IDS 11.10, сервер динамически конфигурирует дополнительные ВП асинхронного ввода/вывода. Хотя общий вывод и говорит, что аппаратное зеркалирование работает быстрее, чем программное, но и в этом случае производительность сильно зависит от контроллера, который осуществляет операции записи. Второй недостаток зеркалирования средствами Informix – это невозможность зеркалировать отдельный чанк db-пространства, вы должны зеркалировать все db-пространство. Несколько лет назад покупка диска для хранения зеркальной копии было дорогим удовольствием. Сегодня цены значительно снизились. Но повысились и требуемые объемы дисков, поэтому нельзя сказать, что зеркалирование стало дешевле, чем в старые добрые времена, когда диски стоили по доллару за мегабайт. Теперь поговорим о преимуществах. Поскольку именно сервер БД контролирует запись на диск, по коду возврата операции записи он может решить, что делать при сбое операции записи. Например, передать данные об ошибки приложению или аппаратному контроллеру. Второе преимущество – улучшенная производительность. Сервер может использовать зеркальные копии для чтения данных наряду с первичными дисками. Эта технология носит название расщепляющее чтение(split read). В OLAP-ориентированных БД, где много последовательных операций чтения, расщепляющее чтение позволяет выполнять сканирование таблиц параллельно, что приводит к ускорению выполнения запроса. Необходимо отметить, что зеркалирование позволяет защитить данные от механического сбоя оборудования. RAID В последние несколько лет дисковые массивы (storage arrays) стали стандартом де-факто для хранения данных в больших и не очень компаниях. Массивы бывают самые

разнообразные – от простого набора дисков, подключенного к контроллеру на плате сервера до очень сложных сетевых серверов, снабженных механизмом автоматического архивирования и восстановления дисков. Из-за физических размеров жестких дисков (х, у дюймов) существует ограничение и на размер таких массивов – надо иметь возможность протащить массив в дверь. Обычно массивы оснащаются очень большими по объему жесткими дисками. Все массивы обеспечивают один или несколько уровней RAID для создания логических элементов хранения (logical units LUN). Здесь необходимо сказать о таком моменте: если LUN созданы на основе одних и тех же дисков в массиве, это может привести к снижению производительности работы системы из перегрузки ввода/вывода. Корме того, перед созданием на этих дисках db-пространств необходимо знать и характеристики RAID. Использование RAID подразумевает объединение нескольких физических дисков в RAID-массивы, которые на уровне ОС видно как один большой диск (LUN). Используя RAID, можно разделять данные по дискам или защищать данные от сбоя путем хранения на других дисках зеркальной копии или корректирующих кодов. В некоторых случаях можно делать и то, и это. В случае аппаратного сбоя правильно настроенный RAID позволяет восстановить данные: после замены неисправного диска данные будут восстановлены на новый исправный диск. Для достижения необходимо уровня устойчивости к сбоям необходимо обеспечить избыточность для всего массива. Сюда включаются резервные источники питания, дисковые контроллеры, резервное питание кэша контроллера и т.п. В спецификациях уровней RAID есть некоторые неопределенности, поэтому реализации уровней RAID от разных производителей могут слегка различаться. Хотя существует 7 уровней RAID, большинство производителей предлагает реализацию RAID 0,1,2,3,5,6-уровней. Некоторые производители также поддерживают уровень 0+1 или 10, который является комбинацией уровней 0 и 1. Для более детального знакомства с теорией построения RAID можно почитать книжку «The RAIDbook» Пола Массигла (Paul Massiglia). Для большинства БД-приложений наиболее подходящими являются уровни 0, 1 и их комбинация. Если критичными являются не скорость дисков, а использование их объема, стоит подумать об использовании RAID 5, который также применяется при построении витрин данных. Теперь давайте рассмотрим основные уровни RAID детальнее. RAID 0 В RAID 0 (см. рис. 3.2) данные разбиваются на полосы между двумя или большим количеством дисков; это похоже на алгоритм фрагментирования round-robin

Рисунок 3.2 RAID 0 Основное преимущество RAID 0 – ускорение доступа к данным при обработке больших объемов данных. Когда серверу необходимо найти строку данных, поиск ведется на всех дисках массива, и поскольку на каждом диске находится определенная часть данных, строка найдется быстрее, чем в случае использования одного большого диска. При использовании RAID 0, в отличие от фрагментирования по алгоритму round-robin, вы не можете быть уверены, что строка данных целиком находится на одном из дисков массива. Ее элементы могут быть размещены на разных дисках массива, что может привести к неприятностям в случае сбоя одного из дисков массива. В отличие от фрагментирования по выражению, вы не можете указать, как распределять данные между дисками. Поиск строки ведется по всем дискам. Поскольку в RAID 0 диски опрашиваются синхронно, это может привести к задержкам в высоконагруженных OLTP-системах, так как контроллер будет ждать от всех дисков отчета о каждой операции чтения/записи. В OLAP-системах использование RAID 0 производительность может увеличиться, поскольку в этих системах обрабатываются большие объемы данных. Выбор между фрагментированием по алгоритму round-robin и использованием RAID 0 надо делать после серии тестов в вашем окружении. Но при выборе не рассматривайте в качестве аргумента только скорость доступа к данным. Примите во внимание также возможность управлять данными на логическом уровне с помощью команды alter partition. Гораздо легче понять размещение данных в базе данных или таблице с помощью отчета dbschema, чем пересматривать конфигурации экраны RAID. Будьте осторожны. RAID 0 не обеспечивает защиты от сбоев: если какой-то диск массива выйдет из строя – все данные на массиве будут утеряны. Уровень 1 RAID 1 – это просто зеркалирование диска. Этот уровень обеспечивает максимальную доступность данных, но является самым дорогим в реализации.

Рисунок 3.3 RAID 1. Зеркалирование данных дисков В аппаратных реализациях RAID 1 контроллеры RAID мониторят коды возврата от дисков (успешность/неуспешность операции). Если контроллер получает данные, которые он определяет, как сбой диска, то диск выключается из обслуживания, а оставшийся диск продолжает функционировать. При выборе производителя RAID не забудьте уточнить, функционирует ли зеркальный диск синхронно или асинхронно, поскольку это оказывает влияние на производительность. Некоторые производители поддерживают не только зеркалирование 1:1, но и зеркальную замену (mirror spare). Эта замена является суррогатным зеркальным диском для «выжившего» диска в зеркальной паре и обеспечивает зеркалирование даже в случае сбоя одного диска. Теоретически и в зависимости от того, сколько дисков вы объединили в массив RAID 1, вы сможете заменить сбойный диск и восстановить зеркалирование. Некоторые производители позволяют сконфигурировать более одного диска зеркальной замены, что повышает надежность массива. Не забывайте тестировать производительность RAID 1 и зеркалирования средствами Informix. Одно из основных преимуществ аппаратных RAID – возможность «горячей замены» дисков: вы можете вытащить поврежденный диск из массива и поставить на его место исправный без остановки сервера или RAID-массива. Но эту возможность обязательно необходимо протестировать перед применением – работает ли она, как необходимо, и не приводит ли ее использование к сбою работы всего массива. Если вы для замены сбойного диска останавливаете сервер, то можете сберечь деньги, используя зеркалирование средствами Informix. Но использование RAID 1 может принести в вашей ситуации и увеличение производительности. Уровень 0+1/10 На рисунке 3.4 представлена графическая иллюстрация этого уровня RAID: этот уровень предполагает зеркалирование RAID 0.

Рисунок 3.4 RAID 0+1 Зеркалирование чередующихся данных. Этот уровень RAID позволяет объединить преимущество RAID 0 в скорости с преимуществом RAID 1 в надежности. Так как это «неофициальный» уровень RAID, его реализации могут быть самые разнообразные. Поэтому перед использованием этого уровня необходимо выполнить набор тестов для проверки скорости работы и совместимости его с вашим окружением. Уровни 5 и 6 Это самые популярные и самые медленные уровни RAID. Эти уровни RAID можно применять, если скорость доступа не является критической величиной и когда большинство операций в базе являются операциями чтения, а не записи. Уровни 5 и 6 практически идентичны: для хранения данных используется 75% дискового пространства, а оставшиеся 25% предназначены для хранения контрольных кодов, рассчитанных по специальному алгоритму коррекции ошибок (код Хемминга). На рисунках 3.5 и 3.6 приведена графическая иллюстрация RAID 5 и RAID 6. В RAID 5 биты четности отдельного диска размещены на всех остальных дисках массива. В RAID 6 на дисках массива записывается не только информация о четности, но и второй набор контрольных битов, инверсный первому. Это позволяет массиву оставаться работоспособным даже после выхода из строя двух дисков. Скорость дискового ввода/вывода при использовании этих уровней RAID мала из-за того, что записывается не только информация на целевой диск, но и информация о четности на все остальные диски. Преимущество RAID-массивов этих уровней состоит в том, что их использование обеспечивает неплохую сохранность данных и требует меньше дискового пространства, чем использование RAID 1. При использовании RAID 5/6 желательно иметь контроллер с большим объемом кэш-памяти. Это требование увеличивает стоимость реализации массива. Программные RAID Некоторые возможности аппаратных RAID можно получить путем использования возможностей ОС. Обычно ОС поддерживает RAID 0,1,5. технология программных RAID имеет много недостатков. Один из основных - необходимые вычисления проводятся центральным процессором сервера, а не специальным процессором RAID-контроллера.

Это значит, что ресурсы процессора тратятся не на работу сервера БД и обработку пользовательских запросов, а на расчет корректирующих кодов. В отличие от аппаратных решений, программные решения не допускают горячей замены сбойных дисков, поэтому для замены такого диска необходимо останавливать сервер. Что выбрать? Что вам следует выбрать из всего этого многообразия? Ответ зависит от ваших приоритетов и финансовых возможностей. Если важна высокая доступность – используйте RAID 1 или зеркалирование Informix. Для большей производительности операций, работающих с большими блоками данных, например, для OLAP, и в случае если вы готовы пожертвовать надежностью в пользу скорости, используйте RAID 0. Если вы, как обычно, хотите и скорости работы и защиты от сбоя, выбирайте RAID-контроллер, который поддерживает RAID 10. если стоимость важнее производительности, смотрите в сторону RAID 5,6. А если стоимость является основополагающим фактором, используйте программный RAID средствами ОС. Что использовать для db-пространств: выделенные файлы или сырое пространство? В части 1 говорилось, что исторически под UNIX/Linux db-пространства создавались на сырых дисках (неформатированное дисковое пространство). Потом быстрое развитие дисковых массивов позволило многим заказчикам начать использование файлов для хранения чанков и db-пространств. Раньше была разница в производительности сервера БД при использовании сырых устройств и выделенных файлов. Это объясняется тем, что запись в файл и чтение из него выполнялось средствами ОС. В IDS 11 добавлен новый конфигурационный параметр DIRECT_IO, установка которого позволяет серверу писать прямо в файлы, где хранятся чанки и db-пространства. Использование этой возможности позволяет достичь производительности, сопоставимой с производительностью при использовании сырого пространства. Эта возможность является платформо-зависимой, поэтому перед ее использованием проконсультируйтесь с документацией по вашей версии Informix. При использовании этой опции не забывайте об ограничениях ОС и файловой системы на размер файла. Кроме того, учтите, что дополнительное пространство для файлов будет выделяться средствами ОС, и это пространство не будет непрерывным (в отличие от использования сырого пространства). Определить, приведет ли необходимость в дополнительном поиске по диску к замедлению работы системы – это ваша задача. Я полагаю, что нет. Заключительные мысли по этой теме. При создании файлов для чанков в Windows, обязательно соблюдайте соглашения об именовании файлов (мы их рассмотрим чуть позже). Хотя возможно в рамках экземпляра использовать и выделенные файлы, и сырые устройства, но делать этого не следует. Если поддержкой вашей системы занимается непрофессиональная команда, то в этом случае безопаснее использовать сырые диски, поскольку в таком случае невозможно будет удалить файлы базы данных из-за ошибки в команде rm. Кроме того, малоквалифицированный инженер поддержки вряд ли полезет монтировать или форматировать сырые диски. Я не хочу говорить, что сырые диски полностью снимут вышеизложенную проблему, но их использование может снизить риск повреждения базы данных. Использование символических ссылок Неважно, используете ли вы файлы или сырые устройства на сервере под управлением UNIX/Linux, но при передачи пути к ним в утилиты командной строки, при редактировании конфигурационных файлов, при вызове административных API-функций вам следует использовать не полный путь к этим устройствам/файлам, а символические ссылки на них. Есть несколько причин использовать символические ссылки. Первая –

возможность перенести окружение на другие диски или на другой сервер. Сейчас я расскажу случай из собственной практики, почему использование символических ссылок предпочтительнее. Однажды я работал с экземпляром, где использовались имена устройств из схемы разбиения диска. В один прекрасный момент диск поломался, и я заменил его диском такой же модели, но на котором было меньше свободного пространства, чем на оригинальном. Поскольку в окружении использовались имена устройств, а второго запасного диска не было, я был вынужден использовать этот. К счастью, хотя на диске было меньше свободного места, но последний раздел оригинального диска не использовался для хранения чанков. Если бы мы использовали символические ссылки и мне нужен был последний раздел диска, то я бы поступил так: откусил бы кусок необходимого мне пространства от другого диска или бы объединил два физических диска в один логический, а затем отредактировал бы символическую ссылку, чтобы она указывала туда, где я создал новое пространство. Эти мероприятия не повлияли бы на экземпляр. Нужно ли вам переместить базу данных из одной части массива в другую или сменить формат диска (например, перенести базу на RAID 0) – в любом случае использование символических ссылок сделает этот процесс проще, особенно если используется зеркалирование средствами Informix. Процесс состоит из нескольких шагов:

сконфигурировать новые диски отключить зеркалирование пересоздать символические ссылки на зеркальные копии так, чтобы эти ссылки

указывали на новые диски включить зеркалирование и дождаться восстановления теперь зеркальная копия восстановлена. Повторить шаги для первичных чанков

Если вы переезжаете на новый сервер, которого достаточно для корректного восстановления БД, то использование символических ссылок позволит избежать проблем, связанных с дисками и лентами. Создайте ту же структуру каталогов, как и на исходном сервере, создайте необходимые символические ссылки и выполните восстановление из архива (в части 7 мы рассмотрим второй метод изменения местонахождения устройств, который называется «перенаправленное восстановление» (redirected restore) ). Второе преимущество символических ссылок – возможность соблюдать соглашения по именованию. Символические ссылки дают возможность проще анализировать физическую реализацию дизайна окружения. Поскольку команда onstat –d возвращает путь к устройствам, на которых созданы чанки, использование символических ссылок с понятными именами может упростить администрирование системы, и вам не придется смотреть на такое: /dev/rdsk/c0b0t2d0s5. Создать символические ссылки очень просто. Ниже скажу, что при установке сервера, я создаю подкаталог devices. В этом подкаталоге создаю подкаталоги для каждого экземпляра, который будет работать на этом сервере. Для всех чанков экземпляра в соответствующем каталоге создаются символические ссылки. Для создания символической ссылки применяется такой синтаксис: ln –s имя_устройства желаемое_символическое_имя Давайте, например, создадим в каталоге /opt/IBM/Informix/devices/styx символическую ссылку styx_chnk_1 на сырое устройство. ln –s /dev/rdsk/c3b0t4d0s3 styx_chnk_1 Обязательно не забудьте выставить права на устройства, на которые указывают символические ссылки. Для установки владельца и группы используются команды chown

и chgrp. Владельцем устройств, которые используются экземпляром Informix, должен быть пользователь и группа informix. Права на файл должны быть 660 или rw-rw----. Работа с выделенными файлами Процесс создания и использования выделенных файлов в Linux, Mac OS X, UNIX не сложен. Перейдите в каталог, где вы хотите создать файл, и для создания файла используйте команду touch. Установите владельца, группу и права доступа так, как указано в предыдущем разделе. В листинге 3.1 показан процесс создания нескольких файлов, которые будут использоваться для хранения db-пространств экземпляра/ # # cd /ifmx_data/tagus # touch r_dbs chnk1 # # chmod 660 r_dbs chnk1 # chown informix r_dbs # chgrp informix r_dbs # # chown informix:informix chnk1 # ls –l rw-rw---- informix informix 18:34 0 r_dbs rw-rw---- informix informix 18:34 0 chnk1 Листинг 3.1. создание выделенных файлов для экземпляра

Когда вы используете файл для создания чанка или db-пространства, файл будет расширяться до размера, указанного при создании db-пространства или чанка. Не забудьте, что на расширение файла будут влиять параметры ядра. В документации на сервер есть рекомендации по настройке ОС для поддержки больших файлов. Не забудьте прочитать эти рекомендации и инструкции по настройке ОС. После создания выделенных файлов вы можете обращаться к ним по символической ссылке, как это было показано ранее. В Windows-версиях IDS вы обязаны следовать соглашению по именованию и размещению файлов для чанков и db-пространств. Более подробно мы поговорим об этом в части 5. Вопросы проектирования db-пространств. Процесс создания чанков и db-пространств на дисках , а затем размещения в них таблиц на 2/3 является наукой, а на оставшуюся треть – это пробы и ошибки. Я обращал на это ваше внимание в начале раздела, когда говорил о важности логического проектирования базы данных. Типы и частота запросов DML, количество и размер таблиц в базе, допустимая гранулярность восстановления – все это повлияет на то, сколько db-пространств вы создадите и как они будут организованы. Основная цель при переходе с логического уровня на физический – равномерно распределить нагрузку ввода/вывода между всеми дисками в системе. Администраторов массивов заставляют бороться за максимальное использование дискового пространства и минимальное администрирование массива. С их точки зрения это значит создание массива RAID 5 или RAID 6 из всех дисков системы. Часто контроллеры RAID имеют большую память, но с точки зрения Informix это бесполезно. Дизайн RAID требует участия всех дисков в операциях ввода/вывода. Если на массиве создано 5-10 LUN, ввод/вывод в эти LUN будет сериализован. Сервер держит наиболее часто используемые данные в своем буфере

памяти, скорость доступа к которому значительно больше, чем скорость доступа к массиву. Сервер даже выполняет упреждающее чтение, если план запроса показывает необходимость в последовательном чтении. Единственное место, где наличие памяти контроллера является плюсом - это операции записи. Вместо ожидания завершения операции ввода/вывода данные помещаются в кэш-память контроллера и экземпляру возвращается ответ, что запись завершена. В этом случае крайне важным является наличие нескольких уровней защиты кэш-памяти контроллера. В противном случае рано или поздно данные будут в несогласованном виде, когда транзакция подтверждена, но данные из кэш-памяти не были записаны на диск. Хотя это и крайне сложно, попробуйте заставить администраторов массива выделить для базы данных отдельные диски, а затем попытайтесь сделать так, чтобы одному физическому диску соответствовал один логический. Если вы создадите много чанков на нескольких больших дисках, вам не удастся полностью распараллелить дисковый ввод/вывод. Можно попробовать купить более старые модели систем хранения с дисками меньшего объема. Это может обойтись дешевле и помочь вам избежать конкуренции дискового ввода/вывода. В конце обсуждения давайте представим, что мы живем в идеальном мире и можем администрировать дисковые массивы так, как захотим. Не будут еще раз напоминать, насколько важно в OLTP-системе помещать наиболее активно используемые таблицы или их фрагменты в db-пространства на отдельных дисках или на дисках, где хранятся db-пространства с малоиспользуемыми таблицами. Это же утверждение справедливо и для индексов. При использовании сырых разделов старайтесь помещать db-пространства с активно используемыми таблицами ближе к центру диска. При использовании зеркалирования сторонними средствами или средствами IDS не только держите исходные данные и их зеркальные копии на разных дисках, но и подключите эти диски к разным контроллерам. Это наука. После того, как будут настроены и запущены экземпляр, база данных и клиентское приложение, вы увидите, насколько теория была близкой к практике и сможете внести необходимые изменения. Здесь приходится идти методом проб и ошибок. На помощь в этой работе придет гибкость IDS. используя фрагментирование по выражению вы можете безболезненно разнести таблицу по разным db-пространствам и сбалансировать нагрузку по вводу/выводу. С версии IDS 10 для административных целей создавать несколько фрагментов таблицы в одном или нескольких db-пространствах. Разработчики Informix рекомендуют соответствие чанков db-пространствам 1:1 (не очень ясно. Наверное, понимать так, что db-пространство должно состоять из одного чанка. IDS development recommends a 1:1 correspondence of disk chunks to dbspaces ). Некоторые идут дальше и рекомендуют класть в db-пространство или несколько маленьких таблиц, или фрагмент одной большой таблицы. Если учесть новые возможности архивирования/восстановления и наличие параметра DATASKIP, такая рекомендация имеет смысл. Установка параметра DATASKIP позволяет экземпляру функционировать даже если db-пространства находятся оффлайн, если это только не корневое db-пространство или db-пространства, содержащие физический журнал или любой из логических журналов. По-прежнему будут доступны запросы к таблице, фрагменты которой хранятся в отключенных db-пространствах. Конечно, данные из отключенных db-пространств получить будет невозможно и приложению будет возвращена ошибка, сигнализирующая о том, что часть данных находится в отключенных db-пространствах. IDS поддерживает возможность «теплого восстановления» некритичных db-пространств. Вы можете восстановить оффлайн db-пространства не останавливая экземпляр. В части 7 мы рассмотрим подробно процесс архивирования и восстановления. Если вы следуете рекомендации по взаимному соответствию чанк-db-пространство (1:1 chunk-to-dbspace recommendation ) и рекомендациям по расположению таблиц в db-

пространствах, то в случае сбоя всего db-пространства недоступными будут фрагмент большой таблицы или несколько маленьких таблиц. Все это можно восстановить за относительно короткое время. Еще одно замечание – не экономьте на предполагаемых размерах db-пространств. Как только вы начнете работать в новом окружении, обязательно начнется непредусмотренный рост таблиц или потребуется хранить новые элементы данных. Я видел много компаний, где дисковые массивы закупались без расчета будущего роста. Через некоторое время складывалась ситуация, где надо было или удалять часть данных, или закупать дополнительное оборудование, или мирится с замедлением дискового ввода/вывода. С точки зрения долговременной перспективы всегда дороже не думать о возможном росте. Настройка ядра Как я говорил в части 1, в IDS обработка данных и пользовательских запросов производится с помощью виртуальных процессоров, в частности, CPU, AIO ВП. Каждый из этих ВП представляет собой процесс операционной системы UNIX, Mac OS X, Linux. Эти процессы являются многопоточными, поэтому используют много системных ресурсов. Если на физическом сервере планируется запускать несколько экземпляров IDS, надо настроить сервер для высоконагруженного окружения. В частности надо отконфигурировать параметры разделяемой памяти и процессов. Экземпляру для каждого ВП требуется семафор и подсоединение к разделяемой памяти. Необходимо также сконфигурировать «наборы» семафоров. На каждые 100 пользовательских сессий в разделяемой памяти требуется такой набор. Также необходим набор семафоров для каждой группы из 100 или меньше ВП. На физическом сервере, где работает один экземпляр Informix проверьте, что параметр ядра SHMMAX (или подобный) установлен так, что вы сможете выделить на один блок памяти больше, чем максимально требует экземпляр. На сервере, где выполняется несколько экземпляров IDS, значение параметра SHMMAX должно превышать суммарное количество памяти, требуемой всеми экземплярами сервера. При использовании выделенных файлов необходимо проверить параметры ulimit, буферов ввода/вывода ФС. Как говорилось выше, набор документов по инсталляции для UNIX, Linux, Mac OS X доступен в каталоге SERVER/doc. После установки полный набор документации, замечаний к выпуску и т.п находится в подкаталоге release каталога $INFORMIXDIR. Особое внимание обратите на документ ids_machine_notes_versionnum, где versionnum – версия вашего IDS. этот документ есть в формате обычного текста и в формате HTML. В этом файле указаны параметры настройки ядра для вашей ОС, технические спецификации на $SQLHOSTS и другие конфигурационные файлы, список патчей на ОС, которые использовались разработчиками, описание нововведений в версии и т.п. Обязательно посмотрите параметры настройки ядра. Группа разработки IDS дает рекомендации по ним на основе конфигурирования и тестирования продукта во время его разработки и проверки. Использование средств мониторинга системы поможет вам увидеть, насколько рекомендуемые параметры применимы в вашем окружении. Может оказаться необходимым внесение изменений вэти параметры для достижения большей производительности. Это тоже часть изучения Informix Dynamic Server. Стратегии архивирования. Один из важных вопросов проектирования – как и когда вы будете архивировать экземпляры IDS (в том числе журналы). Эти архивы спасут вас от двух проблем, то которых не убережет никакой RAID – от кривого пользовательского ввода и от полного разрушения RAID по какой-либо причине. Прежде, чем мы начнем обсуждать стратегии архивирования, необходимо сделать важное замечание по истории Informix. С самого

начала IDS имел возможность делать полный или инкрементальный архив в то время, когда экземпляр был он-лайн и полностью функционировал. Эта возможность IDS существенно упрощает жизнь администратора. В IDS есть две программы для архивирования и восстановления, каждая со своими сильными и слабыми сторонами. Программа ontape используется с самой первой версии сервера Informix и используется многими крупными и мелкими компаниями, несмотря на то, что появились различные альтернативы. В версиях до IDS 10 ontaoe требовала ответов на приглашение во время архивирования, что затрудняло автоматизацию операций, сейчас этот вопрос неактуален. Программа архивирует весь экземпляр, начиная с 0-го чанка и до последнего чанка. В последних версиях функциональность ontape была расширена. Программа все равно производит архивирование всего экземпляра, но восстановление можно вести на уровне db-пространств. Если db-пространство не содержит критичных для функционирования экземпляра элементов (корневое db-пространство, физический журнал или какой-либо из логических журналов), восстановление такого db-пространства может проводится в то время, когда экземпляр находится он-лайн. Программа ontape поддерживает несколько типов ленточных устройств. Это 4-миллиметровые и 8-миллиметровые стримеры DAT-картриджи и четвертьдюймовые стримеры (QIC), подключенные напрямую к физическому серверу. Не поддерживаются ленточные библиотеки (autochangers, jukeboxes). В IDS 10, IDS 11 ontape может архивировать данные и на диск. Эти усовершенствования мы обсудим в части 7. В случае крайней необходимости вы можете архивировать данные на удаленные устройства, расположенные на других системах, но делать так не рекомендуется. Сообщения от удаленной системы о закрытии устройства в конце архивирования не приходит, поэтому процесс архивирования корректно не заканчивается, и его надо останавливать руками. Например, архивирование логических журналов на удаленное устройство остановится после архивации первого журнала. Команда ontape –c не получит подтверждения о записи первого журнала на диск, следовательно после заполнения второго журнала процесс архивирования оставит этот журнал на диске, поскольку первый журнал еще не записан на ленту. В конечном итоге это приведет к заполнению всех журналов, если вы только не включили динамическое создание журналов. А включенное динамическое создание журналов приведет к заполнению диска незаархивированными журналами. Для архивирования и восстановления может также применяться набор программ ON-Bar. Этот комплекс состоит из двух компонентов: ON-Bar API и Informix Server Manager (ISM) –системы управления лентой, которая взаимодействует с API. Перед IDS 10 ON-Bar была предпочтительным выбором для автоматических операций архивирования, но в IDS 11 функциональность ontape была расширена. Выбирать вам. Обе программы являются прекрасным выбором. С помощью ON-Bar ISM или стороннего приложения вы можете выполнять частичное (warm) и полное архивирование и восстановление экземпляра есть возможность выполнить восстановление базы на определенный момент времени. Архивирование и восстановление может выполняться в несколько потоков и на несколько устройств, что уменьшает время архивирования и восстановления. В IDS 11 в ON-Bar добавлен дополнительный функционал. Мы обсудим его в части 7. Ниже приведены некоторые замечания, которые необходимо принять во внимание при разработке стратегии архивирования. Хотя я использую термин «база данных», эти же рассуждения применимы и к экземпляру

насколько критичны данные? Естественно все данные необходимы, иначе зачем их архивировать, но какое время допустимо на восстановление?

Сможете вы восстановить данные? Какие затраты необходимы ? Каково допустимое время полного восстановления? Каково допустимое время

восстановления db-пространства, содержащего часть важной таблицы или набор статических справочных таблиц?

How important is it that you can recover to an approximate moment in time? Ответы на эти вопросы определят, будете ли вы архивировать логические журналы на ленту, как часто вы будете архивировать экземпляр и какой уровень архива будете использовать. Эти решения также повлияют на проектирование db-пространств (количество db-пространств, их размер, размещение таблиц по db-пространствам). Мы подробно обсудим эти вопросы в части 7. На эти же вопросы необходимо будет ответить при настройке репликации. О настройке репликации мы поговорим во второй книге. Настройка окружения. Перед запуском инсталлятора Informix необходимо создать или изменить некоторые файлы и установить некоторые переменные окружения. Я ограничусь рассмотрением настроек сервера. С точки зрения клиента существует много путей подключения к серверу. Для не-UNIX клиентов необходимо настроить драйвер ODBC или JDBC. Корректная настройка драйвера включает в себя установку имени экземпляра, имени физического сервера, номера порта для соединения и некоторых других переменных. Настройку клиента оставляю на упражнение читателю Подготовка места инсталляции Как сказал Король Белому Кролику в «Алиса в стране чудес»: «Начнем сначала». На первом шаге необходимо определиться, куда ставить сервер и как организовать структуру каталогов для безболезненного администрирования, обновления. Я имею свои представления об этом вопросе на основе многолетнего опыта администрирования IDS и решения проблем многих заказчиков. Нижеприведенные советы справедливы для UNIX, Linux, Mac OS X . Windows имеет свои принципы администрирования. По моему мнению необходимо вынести столько компонент, сколько возможно, из каталога двоичных файлов $INFORMIXDIR. В $INFORMIXDIR необходимо устанавливать только двоичные файлы сервера и DataBlade’ов. Вес остальное желательно вынести в отдельные каталоги, как показано на Рис. 3.7

Рисунок 3.7. Рекомендованная структура каталогов для установки IDS В примере сервер БД устанавливается согласно общим стандартам IBM в каталог /opt/IBM/product_name. Для каждого отдельного релиза (10, 11.50) создан отдельный каталог, так что на сервере может работать более одной версии. Эта же структура упрощает миграции между различными версиями. На Mac OS X директория для установки по умолчанию /Applications/IBM/Informix. Вы можете выбрать следовать ли соглашению Mac OS X по установке программ или использовать каталог /opt. Если кроме серверов Mac OS X вы поддерживаете сервера на других ОС, я рекомендую проводить установку в каталог /opt. Это сделает переносимыми ваши скрипты и другие утилиты. Если вы новичок в IDS, то лучше следуйте соглашениям Mac OS X /Applications/IBM/Informix. Каталог scripts содержит в себе административные скрипты архивирования, управления логическими журналами, внешние программы ALARMPROGRAM, задачи и т.п В каталоге devices находятся подкаталоги каждого экземпляра, сконфигурированного на физическом сервере. В примере на сервере сконфигурированы экземпляры koetari, odra. В подкаталогах хранятся символические ссылки на физические устройства (диск и стример), сконфигурированные для экземпляра.

В отдельные каталоги я при необходимости устанавливаю Informix Server Administrator (ISA) или Open Admin Tool. Все журналы экземпляров я складываю в один каталог, что позволяет быстро находить всю необходимую информацию. Чтобы не запутаться в том, какому экземпляру принадлежит журнал, я использую соглашение по именованию журналов. Журналы двухнедельной давности с помощью скрипта из каталога scripts перемещаются в подкаталог old_logs. Каталог backups я часто выношу в отдельную файловую систему. Для архивов также используется соглашение по именованию. Через некоторое время, в соответствии с бизнес-правилами, архивы удаляются с файловой системы с помощью скрипта из каталога scripts.

В каталоге shared_libs находятся объектные файлы определенных пользователем процедур (UDR), написанных на С. При такой структуре каталогов легко переходить между версиями Informix. Я могу изменить переменную среды $INFORMIXDIR с /opt/IBM/Informix/10 на /opt/IBM/Informix/11_50 и наоборот. Обязательно учтите, что кроме переменной $INFORMIXDIR необходимо отредактировать $SQLHOSTS и $ONCONFIG. Вышеприведенный подход прекрасно работает на Linux, Mac OS X, UNIX, но на Windows это не совсем так из-за ограничений, накладываемых использованием системного реестра. В настоящее время некоторые пути жестко закодированы в программе установки и не могут быть изменены. Я надеюсь, что в следующих выпусках IDS эти ограничения будут сняты. Требуемые файлы Если исключить символические ссылки на чанки и ленточные устройства, то перед инициализацией IDS необходимо отредактировать три файла. Первый из них получается путем редактирования шаблона $INFORMIXDIR/etc/onconfig.std. Для двух других: $INFORMIXDIR/etc/sqlhosts и /etc/services шаблона нет. Давайте подробнее рассмотрим эти файлы, а заодно и некоторые переменные окружения. Которые необходимо установить. Файл $ONCONFIG В файле хранятся параметры, необходимые для создания структур разделяемой памяти экземпляра. В нем также находятся данные о наиболее важных физических устройствах, необходимых серверу для инициализации или восстановления, и параметры , необходимые для работы дополнительной функциональности экземпляра (репликация данных, кэширование выражений SQL и .т.п). для каждого экземпляра Informix на физическом сервере должен быть создан отдельный файл $ONCONFIG. Шаблон этого файла называется onconfig.std и при корректной установке IDS находится в каталоге $INFORMIXDIR/etc. Для того, чтобы использовать этот файл, вы должны скопировать его в тот же каталог под уникальным именем. Имя может быть любое, но большинство администраторов в имени файла используют слово «onconfig». Я обычно называю файл onconfig.instance_name, где instance_name – полное или сокращенное имя экземпляра, параметры которого хранятся в файле. Например, при написании книги я использовал для именования экземпляров названия рек – Amazon, Columbia, Kern, Styx. Файлы $ONCONFIG для этих экземпляров называются onconfig.ama, onconfig.col и т.д. в Части 4 я подробно объясню значение некоторых параметров $ONCONFIG. Важно не изменять права доступа к файлу $ONCONFIG: просто скопируйте права доступа с шаблона onconfig.std. также не удаляйте и не изменяйте шаблон onconfig.std. Если файл $ONCONFIG доступен для записи и кто-то туда запишет чего-нибудь лишнего, при последующем переходе из режима оффлайн экземпляр может просто не запуститься. Начиная с IDS 10 сервер проверяет права доступа к этому и еще нескольким критическим файлам, и если права установлены некорректно – сервер выбрасывает ошибку. Когда вы первый раз запускаете экземпляр – файл $ONCONFIG необходимо отредактировать. Во время функционирования экземпляра вам, возможно, также потребуется его редактировать. При редактировании будьте очень внимательны и осторожны. Одна опечатка может привести к разрушению экземпляра. В Windows во время инициализации экземпляра у вас нет возможности поменять имя файла $ONCONFIG. Процесс инсталляции и инициализации создает копию файла под уникальным именем – имя примерно соответствует правилам именования, которыми я

пользуюсь, но содержит полное имя экземпляра onconfig.instance_name. Вы можете переименовать файл, но я рекомендую этого не делать. Если вы все же желаете это сделать – перезапишите значение ключа $ONCONFIG в ветке реестра HKEY_LOCAL_MACHINE\Software\Informix\OnLine\instance_name\Environment. Перед редактированием файла обязательно сохраняйте копию старого экземпляра и только потом перезагружайте экземпляр. Файл $SQLHOSTS Файл $INFORMIXDIR/etc/sqlhosts предназначен для соединения с сервером по сети. Я сравниваю этот файл с телефонной книгой IDS – он указывает, по какому коммуникационному протоколу можно связаться с экземпляром. Файл используется клиентскими приложениями для связи с экземплярами IDS. экземпляры также используют этот файл при проведении распределенных операций. При инсталляции сервера устанавливается шаблон этого файла sqlhosts.std. В отличие от onconfig.std, который изменять нельзя, я переименовываю этот файл в sqlhosts и изменяю в нем то, что мне нужно. В таблице 3.1 представлен формат файла – он достаточно прост. Файл представляет собой строку из 5 полей, каждое поле отделено от другого табуляцией или пробелом. Для каждого экземпляра или псевдонима экземпляра в файле должна быть отдельная строка.

Таблица 3.1 Формат файла $SQLHOSTS Номер поля Описание

1 Имя или псевдоним экземпляра

2 Сетевое «слово» экземпляра (The nettype “word” for instance)

3 Имя физического сервера, на котором работает экземпляр. Максимальная длина – 256 символов

4 Сетевое «имя службы» или номер порта, который будет использоваться для подключения к экземпляру. Максимальная длина – 128 символов.

5 Опции подключения к экземпляру

В этой книге мы рассмотрим базовые настройки этого файла. Если вы используете Enterprise Replication (ER), шифрование соединения или другие дополнительные возможности, то в некоторых из этих полей необходимо сделать дополнительные настройки. О них мы подробно поговорим во второй книге. Поле 1. Имя экземпляра. Первое поле строки содержит имя экземпляра (DBSERVERNAME) или псевдоним экземпляра (DBSERVERALIAS). Имя должно быть уникально для всех экземпляров в сети.

Поле 2.Сетевое «слово» Во втором поле описывается сетевой протокол и тип интерфейса, необходимые для подключения к экземпляру. Это поле состоит из 8-символьного «слова», разделенного на три части, как показано в таблице 3.2

Таблица 3.2 Компоненты сетевого «слова»

Номер компонента

Описание

1 Тип сервера

2 Сетевой интерфейс

3 Сетевой протокол

В Таблице 3.3 показано, как организованы компоненты (они регистрочувствительны) сетевого «слова» и каковы их возможные значения.

Таблица 3.3 Возможные значения каждого компонента сетевого «слова»

Позиция символов

Описание Возможные значения

1-2

Сервер

on – наследие тех времен, когда сервер назывался Informix OnLine. Применяется по умолчанию для всех экземпляров ol – псевдоним для on. Обычно не используется se – IBM Informix Standard Engine dr – соединение на основе DRDA

3-5

Сетевой интерфейс

ipc – интерфейс междупроцессорного взаимодействия. Используется для соединений через разделяемую память tli – интерфейс транспортного уровня soc – интерфейс сокетов

Таблица 3.3 Возможные значения каждого компонента сетевого «слова»

Позиция символов

Описание Возможные значения

6-8

Сетевой протокол

tcp – протокол TCP/IP str – stream-pipe коммуникационный протокол. imc – протокол TCP/IP, используемый с сервером IBM Informix MaxConnect nmp – соединение по именованным каналам spx – протокол IPX/SPX shm – соединение через разделяемую память ssl – интерфейс защищенных сокетов (secure sockets layer SSL). Доступен в IDS 11.5 и последующих

В предыдущих версиях IDS первые два символа поля характеризуют сервер. В IDS 11 обозначение dr применяется для обозначения клиентского соединения Distributed Relational Database Architecture (DRDA), а не IBM Informix Enterprise Gateway. Символы 3-5 определяют сетевой интерфейс, используемый для соединения между клиентским приложением и экземпляром. Обратите внимание на отдельное значение для подключений через разделяемую память (ipc). Это значение предназначено для приложений, работающих на том же физическом сервере, что и экземпляр. Символы 6-8 определяют сетевой протокол, по которому можно связаться с экземпляром. В Таблице 3.4. представлены возможные значения сетевого «слова» для Linux, UNIX, Mac OS X

Таблица 3.4 возможные сетевые «слова» для UNIX, Linux, Mac OS X

Сетевое «слово»

Описание

onipcshm Соединение через разделяемую память

onipcstr Stream-pipe соединение

ontlitcp Протокол TCP/IP поверх интерфейса транспортного уровня (TLI)

onsoctcp Протокол TCP/IP поверх интерфейса сокетов

ontlispx Пртокол IPX/SPX поверх TLI-интерфейса

Таблица 3.4 возможные сетевые «слова» для UNIX, Linux, Mac OS X

Сетевое «слово»

Описание

onsocimc TCP/IP соединение к серверу MaxConnect через интерфейс сокетов

ontliimc TCP/IP соединение к серверу MaxConnect через TLI-интерфейс

drsoctcp DRDA-соединение через TCP/IP сокеты

drtlitcp DRDA-соединение через TCP/IP по TLI-интерфейсу

onsocssl Зашифрованное соединение по TCP/IP через интерфейс сокетов

drsocssl DRDA-соединение через интерфейс сокетов TCP/IP

Для Linux/UNIX/Mac OS X/Windows версий Informix может использоваться еще одно сетевое «слово» onsqlmux – оно предназначено для поддержки приложений, открывающих несколько соединений к серверу БД для каждого пользователя. Например, это могут быть многопоточные приложения, которые открывают соединения к разным базам данных экземпляра. Использование этого сетевого «слова» позволяет снизить административные и ресурсные издержки такого типа соединений. Включение SSL требует не только активации соответствующей возможности в файле $SQLHOSTS. Подробная инструкция приведена в IBM Informix Security Guide. Кроме того, прочитайте замечания по вашей платформе, поскольку эта возможность поддерживается не всеми ОС. Поле 3. Имя хоста Содержит имя физического сервера, на котором работает экземпляр. Имя должно разрешаться через файл /etc/hosts или DNS. Поле 4. Сетевое имя службы. Значение 4-го поля зависит от сетевого «слова» экземпляра. В зависимости от интерфейса и протокола, указанных в 3-м поле, это поле может использоваться в процессе соединения, а может и не использоваться, но в любом случае оно не должно быть пустым. При соединении через разделяемую память (onipcshm) это поле не используется, и вы можете указать в качестве его значения любую произвольную уникальную строку. Для всех остальных соединений указанное в этом поле значение обычно соответствует значению «service name» в файле /etc/services. Это имя сервиса используется как кросс-ссылка на номер порта и протокол, которые используются для подключения к экземпляру по сети. Имя сервиса должно быть уникальным для каждого экземпляра IDS на физическом сервере. В пределах сети это имя не должно быть уникальным, поскольку оно привязано к физическому серверу, но, чтобы не искать лишних приключений, рекомендуется все-таки делать его уникальным. Если вы не хотите вписать в это поле наименование псевдонима, можете просто указать номер порта, но поле должно быть обязательно заполнено, и запись должна быть уникальна в пределах физического сервера. Например, вы используете соединение через разделяемую память или stream-pipe соединение, в этом поле для первого экземпляра можно указать placeholder, для второго – placeholder_2 и т.д.

Посмотрите файл /etc/services и добавьте по образцу необходимые записи для экземпляра IDS. В качестве имени сервиса в этом файле укажите сетевое «имя сервиса» из файла $SQLHOSTS, укажите номер порта, который еще не используется, и используемый сетевой протокол. Номер порта должен быть уникальным для всей сети. На других физических серверах, которым потребуется доступ к этому экземпляру, не забудьте также указать этот номер порта в файле /etc/services этого сервера (All other physical servers hosting instances that need to connect to this instance will need to use the same port number in their /etc/services file) Безопасно выбирать номер порта больше 5500, но для надежности посмотрите документацию по вашей версии Informix на предмет возможных ограничений на номер порта. В MacOS X 10.5.2 и старше в файле /etc/services содержится много записей о занятых портах. Могут быть заняты порты с номерами до 40000, 50000. Поэтому если вы планируете использовать IDS на MAC OS X обязательно сначала найдите диапазон свободных портов, которые будут использоваться всеми остальными экземплярами. Если инсталляции на MAC OS X появились в сети позднее и случился конфликт портов, необходимо или поменять порт службы MACOS или сменить порт, который слушает Informix. Если вы меняете порт Informix, не забудьте поменять его на всех серверах, которые обращаются к этому экземпляру. Поле 5. Опции подключения. В отличие от четырех предыдущих полей, это поле не является обязательным. Назначение этого поля – дать вам возможность указать специфические опции подключения к экземпляру. Мне кажется, надо обязательно указывать одну из опций. Синтаксис указания значений для этого поля такой: option_letter=value где option_letter заменяется буквой, обозначающей определенную опцию. Для каждого экземпляра, если есть необходимость, вы можете указать несколько опций. Каждая указываемая опция должна иметь формат option_letter=value и отделяться от остальных опций запятой или пробелом. Общая длина строки с указанием опций не должна превышать 256 символов. В Таблице 3.5 приведены допустимые значения для этого поля

Таблица 3.5 допустимые опции подключения Буква опции

Описание

b

Размер буфера (в байтах) для протокола TCP/IP

c Перенаправление соединения (connection redirection)

csm Communication Support Module, используется для аутентификации

e Конец определения группы серверов

Таблица 3.5 допустимые опции подключения Буква опции

Описание

g

Начало определения группы серверов. Используется, в основном, в Enterprise Replication, но может быть использовано для автоматического перенаправления клиентов, определения high-availability service level agreement(SLA)

i Используется для указания числового идентификатора группы серверов

m Используется совместно с протоколом sqlmux

r,s Настройки безопасности ОС, r – со стороны клиента, s – со стороны сервера

k

Определяет использование keep-alive

Опция keep-alive. Из всех опций, доступных в поле 5 файла $SQLHOSTS я рекомендую оставить включенной опцию keep-alive (обозначается k) k=0 - опция выключена k=1 – опция включена Эта опция влияет на соединения по TCP/IP и IPX/SPX. При включенном keep-alive периодически проводится проверка связи между пользовательскими потоками экземпляра и клиентским приложением. Если от клиента не поступает ответа за определенное время, пользовательский поток уничтожается, а связанные с ним ресурсы освобождаются. По умолчанию эта опция включена. Для выключения необходимо явно прописать k-0 Опции безопасности. Две опции безопасности (r и s) позволяют контролировать, как проверяется запрос на подключение к экземпляру. При поступлении запроса на подключение сервер проверяет, что User ID, пославшего запрос, и компьютер, с которого послан запрос, являются «known and trusted» в сети. Если User ID, отсутствует, что характерно для клиентских соединений с РС, то проверяется только компьютер, а права пользователя проверяются при обработке команды SQL сonnect. Если не указано обратное, сервер просматривает на клиенте каталоги /etc/hosts.equiv или $HOME/.rhosts для определения может ли взаимодействие клиент/хост быть доверенным (to determine whether the client/host relationship can be trusted). В таблице 3.6 приведены возможные значения опций безопасности

Таблица 3.6 возможные значения для опции безопасности файла $SQLHOSTS

Значение Описание

s=3 Разрешает просмотр /etc/hosts.equiv и ~ /.rhosts на сервере(server-side lookup)

s=2 Разрешает только просмотр ~ /.rhosts на сервере

s=1 Разрешает только просмотр /etc/hosts.equiv на сервере

s=0 Запрещает просмотр /etc/hosts.equiv и ~/.rhosts на сервере

r=1 Разрешает просмотр ~/.netrc на клиенте

r=0 Запрещает просмотр ~/.netrc на клиенте

Процесс проверки состоит из нескольких шагов:

1. User ID подтверждается путем проверки файла /etc/passwd на сервере. Если такой User ID есть на сервере, то он считается подтвержденным

2. Проверяется компьютер, с которого был сделан запрос. Имя клиентского компьютера должно разрешаться либо через файл /etc/hosts сервера, либо через DNS.

3. после разрешения имени клиентского компьютера, делается проверка, считает ли сервер клиентский компьютер доверенным. Если это так, то пароль не требуется

4. если для клиентского компьютера есть запись в файле /etc/hosts.equiv, то происходит подключение к экземпляру. Если записи в файле нет, то проверяется файл ~/.rhosts: есть ли в нем запись для комбинации User ID и имя компьютера. Если такая запись найдена, то осуществляется подключение к экземпляру. В противном случае запрос на подключение отвергается.

Файл ~/.rhosts позволяет клиенту, который имеет учетную запись на сервере IDS и на недоверенном компьютере, осуществлять подключение к экземпляру и базе данных без указания пароля. Этот файл создается в домашнем каталоге пользователя на сервере. Точный формат файла вы можете посмотреть в документации на вашу ОС. Общая форма такая: user_id@remote_host_name Файл .netrc также находится в домашнем каталоге пользователя и разрешает соединение с клиентов, где User ID отличается от User ID на сервере. При создании файла .rhosts или .netrc в окружении, где используется DNS, не забудьте создать запись как для имени удаленного компьютера, так и для имени удаленного компьютера + доменный суффикс Опция безопасности определяет, уровень, до которого доходит сервер при проверке, является ли соединение разрешенным. По умолчанию применяется s=3. установка s=0 предотвращает любой удаленный доступ к серверу, s=2 разрешает только соединение с определенных user ID, s=1 предотвращает доступ с недоверенных хостов.

Опция «размер буфера» Позволяет настраивать размер буфера соединения TCP/IP. По умолчанию размер буфера составляет 4096 байт. Если сервер постоянно занимается пересылкой пакетов, размер которых больше(например, BLOB’ов), используйте эту опцию для указания желаемого размера пакета. Учтите, что каждое клиентское подключение использует свой собственный буфер. При указании размера буфера, убедитесь, что на физическом сервере достаточно памяти для обслуживания этих буферов, экземпляров IDS и других приложений, выполняющихся на сервере. Если вы укажете слишком большое значение этого параметра, то при наличии большого количества подключений к серверу запросы на подключение будут отвергаться. Опции «группа», «конец группы», «номер группы» Серверная группа (server group) – логическое понятие. Как db-пространство – это множество из одного или нескольких чанков, так и серверная группа – псевдоним для множества из одного или более экземпляров. Группы обычно используются в кластере Enterprise Replication. Могут также использоваться для автоматического перенаправления клиентов: если первый экземпляр в списке не отвечает, будет сделана попытка подключиться к другим экземплярам, указанным в списке. Каждая группа имеет свой уникальный числовой идентификатор, определяемый параметром i=number. Определение группы в файле $SQLHOSTS начинается с имени группы в первом поле (максимальная длина имени 18 символов), во втором поле указывается слово group, в третьем и четвертом поле ставится знак – (dash). Затем указываются экземпляры. Определение группы продолжается до конца файла $SQLHOSTS, либо до указания e=parameter. В таблице 3.7 показан пример определения группы.

Таблица 3.7 пример определения групп в файле $SQLHOSTS DBSERVERNAME Nettype Host name Service name Options

er_grp_1 group - - e=tagus_net

cadmus_net onsoctcp host_1 net_1 g=er_grp_1

tagus_net onsoctcp host_2 net_2 g=er_grp_1

amazon onipcshm host_3 placeholder

colorado_net onsoctcp host_4 net_3 k=1,s=2

rio_grande_net ontlitcp host_5 net_5 k=1,b=5124

Таблица 3.7 пример определения групп в файле $SQLHOSTS DBSERVERNAME Nettype Host name Service name Options

er_grp_2 group - -

red_net ontlitcp host_6 net_6

green_net onsoctcp host_8 net_8

yangzi_net ontlitcp host_7 net_7

odra_net onsoctcp host_10 net_10 g=er_grp_1

В таблице приведены определения двух групп – er_grp_1 состоит из экземпляров cadmus_net и tagus_net. В эту группу входит также экземпляр odra_net (членство в группе указано в пятом поле файла). Как видите, определение экземпляров не обязано быть строго последовательным. Группа er_grp_2 состоит из трех экземпляров (достигнут конец файла, а экземпляр odra_net принадлежит к другой группе). Хотя я явно указал для экземпляров группы er_grp_1 членство в этой группе, но это не является обязательным (смотрите отсутствие такого указания для экземпляров группы er_grp_2). Опция перенаправления подключения. Серверные группы можно использовать не только для репликации, но также для автоматического перенаправления клиентов. Эта возможность полезна, когда один или несколько узлов определены как часть meshed ER-топологии (см. Таблицу 3.8)

Таблица 3.8 Пример определения серверных групп с перенаправлением подключения

DBSERVERNAME Nettype Host name Service name

Options

er_grp_1 group - - e=tagus_net,c=1

cadmus_net onsoctcp host_1 net_1

tagus_net onsoctcp host_2 net_2

amazon onipcshm host_3 placeholder

hdr_1 group - - c=2

red_net ontlitcp host_6 net_6

green_net onsoctcp host_8 net_8

yangzi_net ontlitcp host_8 net_8

В таблице определено две группы, к которым может подключаться клиент. Поскольку используется meshed кластер ER-топологии, клиентское приложение может подключаться к любым узлам кластера. Поскольку с=1, клиент будет подключаться к случайному экземпляру группы. Если соединение будет неудачным, будет сделана попытка

подключения к другим экземплярам. В IDS 11.10 было важно, чтобы для проведения операций записи клиент подключался к правильному экземпляру. При указании параметра с=2 клиент сделает попытку подключиться к первому экземпляру группы. Если этот экземпляр не работает, будет выполнена попытка подключения к остальным экземплярам. В версии 11.50 этот процесс стал ненужным, потому что операции обновления могут производиться на любом экземпляре кластера MACH-11 (Multi-Active Cluster for High Availability). В выпуске 11.50 также введен агент Online Connection Manager and Service Monitor (ONCMSM). Кластер MACH-11 мы рассмотрим подробно в следующей книге. Модуль поддержки соединений (Communication Support Module CSM). Включение CSM позволяет шифровать связь между клиентами и серверами БД. Поддерживаются такие алгоритмы шифрования, как DES, Triple DES, Extended DES, AES ( размер ключа 128, 192, 256 бит). Подробно мы это рассмотрим во второй книге. Заключительный совет по опциям соединения пятого поля файла $ SQLHOSTS. Разработчики IDS рекомендуют для уменьшения сетевых нагрузок указывать одинаковый размер коммуникационного буфера на сервере и на клиенте. При изменении опций подключения клиентов (keep-alive, просмотр файла .netrc) эти изменения будут применены ко всем новым соединениям. Изменение серверных параметров требует перезапуска экземпляра. Конфигурирование $SQLHOSTS в Windows Хотя функциональность $SQLHOSTS одинакова для версий под Linux, Mac OS X, UNIX, Windows, но Windows-реализация имеет свои особенности. Она может быть еще сложнее , если вы инсталлируете Informix в домене. Информация %SQLHOSTS% (синтаксис Windows) находится в ветке реестра HKEY_LOCAL_MACHINE\SOFTWARE\Informix. При инсталляции сервера можно указать, где будет располагаться эта ветка реестра: будет ли у каждого сервера своя ветка или на контроллере домена будет одна общая ветка для всех серверов. Если вы решите использовать ветку, расположенную на контроллере домена, на клиентских компьютерах необходимо будет установить дополнительную переменную окружения. %SQLHOSTS% содержит четыре поля: пропущено поле с именем экземпляра. В таблице 3.9 приведено описание полей

Таблица 3.9 поля %SQLHOSTS%

Наименование поля описание

Host Имя физического сервера, на котором работает экземпляр. Максимальная длина 256 символов

Options Опции подключения к экземпляру

Protocol Сетевое «слово» экземпляра

Service Название сетевого сервиса, используемое локальным компьютером для подключения к экземпляру. Максимальная длина 128 символов.

Назначение параметров практически совпадает с назначением параметров версий для UNIX/Linux. В таблице 3.10 отмечены исключения Разница в поддерживаемом синтаксисе и опциях для %SQLHOSTS% Windows

Исключение Описание

Сетевые протоколы, сетевое «слово»

IDS для Windows поддерживает только onipcnmp, onsoctcp, drsoctcp, onsocssl, drsocssl, onsqlmux

Имя сервиса должно быть указано в файле services, который находится в %SYSTEMROOT%\windows\system32\drivers\etc\

если для доступа к экземпляру используется соединение по именованным каналам, то в это поле необходимо внести не название сервиса, соответствующее названию в файле services, а наименование канала, созданного для соединения. Например, предположим, что вы создали канал shrdmem_to_sarthe. Тогда в %SQLHOSTS% необходимо записать имя этого канала \\.PIPE\shrdmem_to_sarthe

Опции безопасности

Поддерживаются только следующие s= опции s=0 отключает просмотр hosts.equiv и ~.rhosts. Если установлено, удаленный доступ к экземпляру запрещен s=1 разрешает только просмотр файла hosts.equiv s=2 не поддерживается в версиях для Windows s=3 разрешает просмотр hosts.equiv и ~.rhosts Это значение по умолчанию.

Размер коммуникационного буфера

В версиях для Windows влияет на размер буфера только для соединений по именованным каналам (named pipe)

Как я уже говорил, конфигурирование окружения IDS на Windows зависит от того, инсталлируется ли сервер в домене или нет. Это особенно влияет на методы идентификации клиентов. Шайлеш Гупта (Shailesh Gupta), бывший архитектор IDS, так объясняет аутентификацию под Windows Когда имя пользователя передается во время соединения, сервер проверяет, совпадают ли имя пользователя и пароль. Аутентификация происходит также, как и при логине пользователя на физический сервер. Если сервер сконфигурирован на проверку учетной записи через NIS или контроллер домена, то сервер БД будет проверять пользователя точно также. Возникает вопрос, откуда сервер «знает», где проверять данные пользователя – на локальном сервере или на контроллере домена. Это определяется тем, как был установлен сервер БД. Если сервер установлен администратором, который локально залогинился на физический сервер (не домен), то это локальная установка и сервер БД предполагает, что вся информация о пользователях хранится на локальном сервере. Если

установка проводилась администратором на контроллере домена, то такая установка называется «доменной». В этом случае пользователи будут проверяться на контроллерах домена. Вышеприведенное справедливо и для инструментов управления , например, для утилиты onmode. Эти утилиты предполагают, что вы являетесь членом группы domain\Informix-Admin или вы пользователь domain\informix. Важно отметить, что клиент может передать имя учетной записи, даже если не используется SQL-команда connect as. На клиенте достаточно иметь файл .netrc На клиентах Windows утилиты setnet, setnet32 автоматически настраивают аналог файла .netrc Это значит, что Windows-клиенты при попытке подключения к экземпляру всегда пересылают имя пользователя и пароль. Если имя пользователя и пароль не совпадают, сервер БД проверяет, выполняется ли клиентское приложение на том же физическом сервере, что и сервер БД. В этом случае аутентификация считается успешной. При проверке сравнивается имя клиентского хоста с именем хоста сервера БД. Если первый и второй шаги провалились, сервер проверяет, не является ли клиент доверенным клиентом (trusted client). Для этого сервер ищет наличие записи в файле %SYSTEMROOT% \windows\system32\drivers\etc\hosts.equiv и затем в файле .rhosts в домашнем каталоге пользователя. В Windows наличие домашнего каталога пользователя не является обязательным, поэтому файл .rhosts не просматривается. Когда в поле опций вы устанавливаете s=параметр, сервер БД устанавливает биты в служебном флаге. Когда сервер в процессе аутентификации доходит до 3-го шага, то в зависимости от установленных параметров он проверяет файл hosts.equiv или файлы hosts.equiv и ~.rhosts, или один из них, в зависимости от установленного флага. Поскольку на Windows файл ~.rhosts никогда не просматривается, то установка s=3сооветствует установке s=1, а установка s=2 не используется. Опция s=3 применяется по умолчанию, поэтому вам не нужно явно устанавливать ее. Установка s=0 запрещает удаленный доступ к экземпляру. Переменные среды. Для работы IDS необходимо определить несколько переменных среды. Некоторые из них определяют, как работает сервер БД, другие влияют на обработку им SQL-запросов. Несколько переменных являются обязательными, другие опциональны и требуют установки только если рабочее окружение отличается от умолчаний IDS. На физическом сервере под управлением UNIX/Linux/Mac OS X, где работает экземпляр, вы можете установить настройки для всех пользователей в файле /etc/profile или $INFORMIXDIR/etc/informix.rc. Эти настройки могут быть перекрыты на уровне пользователи или сессии несколькими путями. В Windows настройки экземпляра хранятся в ветви реестра HKEY_LOCAL_MACHINE\SOFTWARE\Informix\OnLine\instance_name\Environment В этой ветви настраиваются значения %INFORMIXDIR%, %INFORMIXSERVER%, %SQLHOSTS% и другие. При необходимости вы можете изменять эти значения и добавлять новые (тип данных REG_SZ) . Перед изменением настроек я настойчиво рекомендую остановить экземпляр. Эти настройки реестра не используются клиентскими приложениями, которые выполняются на том же физическом сервере, что и экземпляр. Установка правильных переменных окружения может сильно зависеть от типа приложения. Вы можете изменять системные и/или личные переменные окружения, например, %INFORMIXDIR% на вкладке Environment окна System Properties (Control Panel > System). В Windows-инсталляции Informix 11.50 в каталоге %INFORMIXDIR% находится сценарий instance_name.cmd, предназначенный для установки переменных среды.

На клиентском компьютере, в зависимости от типа приложения и того, как оно подключается к экземпляру, может потребоваться установка самых разных переменных среды. Как я говорил выше, вы можете использовать одну универсальную ветвь %SQLHOSTS%, которая расположена на контроллере домена. В этом случае на каждом клиентском компьютере необходимо установить переменную %INFORMIXSQLHOSTS%. Эта переменная должна содержать имя сервера. Например, если %SQLHOSTS% расположен на сервере hestia, то значение переменной %INFORMIXSQLHOSTS% должно быть \\hestia. Ниже приведены самые важные переменные среды. Остальные я буду объяснять на протяжении книги. Полный список переменных среды для сервера и клиента вы можете посмотреть в IBM Informix Guide to SQL:Reference. Необходимые переменные Для инициализации экземпляра и доступа к нему должны быть установлены следующие переменные: $INFORMIXDIR, $ONCONFIG, $INFORMIXSERVER. Также необходимо модифицировать переменную $PATH, и я рекомендую установить переменную $DBEDIT. В Informix 11 можно использовать $INFORMIXDIR и другие переменные среды в файлах $ONCONFIG. $INFORMIXDIR В этой переменной содержится полный путь к каталогу, где находятся двоичные файлы IDS 11. эта переменная должна быть установлена первой. Нет жестких рекомендаций, как называть каталог установки. Вы можете иметь несколько каталогов с разными версиями IDS (например, informix_9_4, informix_10). Для переключения между версиями вам необходимо будет переустановить переменные $INFORMIXDIR, $ONCONFIG, $INFORMIXSERVER и, возможно, $INFORMIXSQLHOSTS, $PATH. Переключение между версиями может быть необходимо для тестирования функционала или поддержки каких-то сторонних приложений. Для пользователей, которым необходимо запускать исполняемые файлы Informix, после установки переменной$INFORMIXDIR необходимо добавить в PATH путь $INFORMIXDIR/bin Если вы разрабатываете приложения на продажу, никогда не программируйте жестко путь к установочному каталогу Informix и не полагайте, что этот каталог будет называться Informix. Всегда считывайте переменную окружения $INFORMIXDIR. Это же замечание справедливо и для скриптов. $ONCONFIG В этой переменной хранится имя файла, который обычно расположен в каталоге $INFORMIXDIR/etc, и в котором записаны параметры конфигурации активного экземпляра. Переменная автоматически указывает на $INFORMIXDIR/etc, поэтому корректный синтаксис для оболочек Bourne или Korn будет выглядеть примерно так: ONCONFIG=onconfig.sty export ONCONFIG $INFORMIXSERVER Имя экземпляра IDS, к которому можно подключаться. Это должно быть значение DBSERVERNAME или одно из значений DBSERVERALIAS из файла $ONCONFIG. Установка этой переменной не означает, что приложения будут вынуждены подключаться именно к этому экземпляру. С помощью SQL-команды connect to

database_name@instance_name или строки подключения вы можете явно указать приложению, куда надо подключаться. В IDS 11.50 при наличии ONCMSM-агента клиенты могут подключаться к service level agreement(SLA) и получать от него информацию, необходимую для подключения к экземпляру, в том числе и значение $INFORMIXSERVER. Одно замечание. С технической точки зрения перед установкой экземпляра нет необходимости устанавливать значение $INFORMIXSERVER. Однако если этого не сделать, при инициализации не будут созданы базы системного каталога. Эти базы являются критичными для корректного функционирования экземпляра. Поэтому я настойчиво рекомендую перед инициализацией экземпляра устанавливать эту переменную. $INFORMIXSQLHOSTS В этой переменной нет необходимости до тех пор, пока вы не меняете имя файла sqlhosts или не перемещаете его из каталога $INFORMIXDIR/etc. Файл, указанный в этой переменной, должен иметь такой же формат, как и стандартный файл sqlhosts. При установке этой переменной файл $INFORMIXDIR/etc/sqlhosts не будет использоваться для подключения к экземпляру. $DBEDIT Эту переменную не нужно обязательно устанавливать перед инициализацией, но я рекомендую это сделать, если вы, конечно, не хотите выбирать каждый раз текстовый редактор при запуске dbaccess или I-SQL. Я устанавливаю для $DBEDIT значение vi, вы можете выбрать свой любимый текстовый редактор. Другие переменные. Для определения того, как IDS обрабатывает данные и отображает их пользователю вы можете установить другие переменные среды, например, $DBDATE, $DBMONEY. Эти переменные рассмотрены в IBM Informix Guide to SQL:Reference. Вопросы мультирезидентности Мультирезидентность – это поддержка запуска нескольких экземпляров IDS одновременно на компьютере. Для поддержки мультирезидентности вам не нужно устанавливать еще одну копию Informix в другой каталог: вы можете скопировать только необходимые файлы и корректно установить переменные среды. Переменная $INFORMIXDIR остается неизменной. В файл $SQLHOSTS вы можете добавить информацию, необходимую для подключения ко всем версиям IDS на этом компьютере. Если вам необходимо поддерживать несколько версий IDS, установленных в разные каталоги, установка переменной $INFORMIXSQLHOSTS позволит всем экземплярам, работающим на физическом сервере, обращаться к одному файлу $SQLHOSTS. В противном случае экземпляры будут использовать файл sqlhosts из своего каталога $INFORMIXDIR/etc. Для каждого экземпляра необходимо создать уникальный файл $ONCONFIG и файл MSGPATH. Имя экземпляра (DBSERVERNAME), псевдоним(-ы) (DBSERVERALIAS) и номер экземпляра (SERVERNUM) должны быть уникальны для каждого экземпляра на всех серверах сети. Как я отмечал выше во всей сети должны быть уникальны DBSERVERNAME и все псевдонимы DBSERVERALIAS. Очевидно, что $ONCONFIG и $INFORMIXSERVER также уникальны для каждого экземпляра. Экземпляры не могут разделять дисковые чанки, если, конечно, вы не используете SDS(Shared Disk Secondary) MACH-11, который доступен в версии IDS 11 и старше. Переменные MSGPATH и номер сервера я объясню в следующей части, посвященной установке и инициализации экземпляра IDS.

Кроме этих изменений, нет ничего сложного в запуске нескольких экземпляров на одном физическом сервере. Первый вопрос, на который необходимо ответить, -достаточно ли аппаратных ресурсов для поддержки нескольких экземпляров. Этот вопрос особенно важен для настройки разделяемой памяти ядра и установки параметра «memory forced resident» в файле $ONCONFIG. В части 4 мы обсудим параметр RESIDENT. В зависимости от количества устройств для архивирования может также потребоваться определенное согласование архивирования логических журналов экземпляров. Заключение При создании любой новой системы необходимо тщательное планирование. Informix Dynamic Server не является исключением. При подготовке к инсталляции и инициализации помните, что принятые вами решения зависят от вашей среды: нет твердых правил и решений. Вашими проводниками будут знания, опыт и интуиция. При планировании развертывания нового экземпляра IDS примите во внимание следующее:

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

Вы обязательно должны позаботиться о защите от сбоев дисков, содержащих корневое db-пространство, файлы логического и физического журнала.

При обращении к дискам и ленточным устройствам используйте символические ссылки, а не имена устройств.

При оценке размеров таблиц и db-пространств не стремитесь сэкономить несколько долларов – в конечном итоге выйдет дороже.

Для освобождения физических ресурсов сервера отключите все лишнее железо и ненужные службы ОС

При использовании мультирезидентности тщательно мониторьте системные ресурсы.

В следующей части мы рассмотрим процесс инсталляции и инициализации экземпляра, конфигурационные параметры и базовые вопросы настройки экземпляра.

Инсталляция и инициализация IDS В этом разделе:

Инсталляция и инициализация продукта Установка основных конфигурационных параметров Системные базы данных Поддержка на сервере нескольких экземпляров

В предыдущих частях книги разговор шел, в основном, об абстрактных вещах. С этой части я начну обсуждать вопросы инициализации, администрирования и настройки экземпляра Informix Dynamic Server. Закончив фазы логического проектирования приложения и базы данных, вы готовы приступить к конфигурации и инициализации экземпляра IDS. в этой части описан процесс инсталляции или обновления сервера базы данных и инициализации экземпляра. Я объясню некоторые наиболее важные параметры файла $ONCONFIG и приведу рекомендации по их значениям. Вы также узнаете, как создать более одного экземпляра IDS на физическом сервере. Кроме того, в этой части я расскажу о системных базах данных. Установка или обновление сервера. В IDS11 компания IBM полностью обновила и, по моему мнению, улучшила процесс установки. Одно из важных улучшений – процесс установки одинаков для версий IDS под разные ОС. Я имею в виду, что процесс установки идентичен для разных ОС на физическом сервере. Но это не значит, что всеми версиями поддерживаются все режимы установки: например, версия под Windows не поддерживает установку из командной строки. Вне зависимости от того, инсталлируете ли вы Informix впервые или проводите обновление сервера, обязательно прочитайте замечания по релизу (release notes) и другие документы. В ранних версиях IDS эти документы были доступны только после установки, сейчас их можно прочитать перед запуском инсталлятора. В них содержаться системные требования, рекомендации по настройке ядра, руководство по установке и т.п. На Linux, Mac OS X, UNIX документация расположена в каталоге $extract_location/SERVER/doc. Файл README.html в этом каталоге содержит ссылки на документы. В Windows документация находится в каталоге %extract_location\IIF\doc. Внимание: в дистрибутиве есть каталог %extract_location\doc, но в нем содержится только информация о Java Runtime Environment (JRE) Обновление с предыдущих версий. Некоторые читатели книги уже безболезненно переходят с IDS 10 на IDS 11, но я полагаю, что многие, в том числе, возможно и вы, переходят с более ранних версий IDS. Если вы смотрели последние релизы Informix, то, наверное, обратили внимание на большое количество новых возможностей. Например, в IDS 9 были добавлены «большие» чанки, новая система управления буфером разделяемой памяти, динамические логические журналы, директивы оптимизатора, сырые таблицы, более эффективная система управления индексами. В IDS 10 появились страницы с конфигурируемым размером, шифрование данных на уровне столбца, восстановление таблиц на определенный момент времени, усовершенствования ER. Итак, как вам обновится до IDS 11 ? в зависимости от используемой версии IDS вы можете обновится либо напрямую, либо через промежуточный шаг. На рисунке 4.1 показан путь миграции .

Рисунок 4.1 Путь миграции на IDS 11 Как видите почти все более-менее новые версии могут быть обновлены сразу до IDS 11. под понятие «сразу» я имею в виду, что вы можете загрузить IDS 11 на физический сервер, остановить экземпляр, обновить двоичные файлы, перезапустить экземпляр и начать использовать IDS 11. это не намного сложнее, чем описано. В версиях, которые невозможно обновить напрямую, отсутствуют некоторые возможности, которые необходимы для перехода на новую версию. Чтобы не раздувать исходные тексты, в IBM было принято решение не включать эти возможности в процесс миграции на IDS 11. при использовании таких версий Informix необходимо выполнить двухступенчатый процесс миграции. Как видите, можно обновиться с IBM OnLine 5.1x и даже с IBM Standard Engine. В случае использования OnLine 5.1x сначала необходимо обновиться до IDS 7.3x, а затем до IDS 11. в случае Standard Engine прямого пути нет – самый простой и быстрый метод состоит в использовании dbexport и dbimport для выгрузки базы и загрузки ее в экземпляр IDS 11. Я полагаю, что вы уже создали тестовую среду и проверили функционирование ваших приложений. Если вы это сделали, то можете приступать к миграции промышленных установок. Проблемы при миграции, в основном, возникают из-за использования слов, зарезервированных в этой версии IDS, в качестве имен объектов базы данных или переменных. В Таблице 4.1 приведен список некоторых зарезервированных слов; он не является полным, полный список вы можете найти в руководстве по миграции (IBM Migration Guide).

Таблица 4.1 Некоторые зарезервированные слова IDS

IDS 9 IDS 10 IDS 11

avoid_execute left active password admin updating avoid_subqf locks directives save avoid_index_sj uselastcommited cache raw encryption table idssecuritylabel with collation retain hint template index_sj costfunc restart inactive test inserting cross right inline typeid references full selconst inout typename sampling inner standard load typeof selecting instead use_subqf online wait sysdbclose

Таблица 4.1 Некоторые зарезервированные слова IDS

IDS 9 IDS 10 IDS 11

item optcompind xadatasource sysdbopen join partition xid task

Процесс непосредственной миграции на IDS 11 состоит из 5-ти основных шагов.

1. подготовка исходных экземпляров (экземпляра) 2. установка новых двоичных файлов сервера 3. переустановка переменных экземпляра 4. перезапуск экземпляра для старта процесса конверсии 5. проверка целостности данных и создание архива

Давайте рассмотри каждый из шагов Шаг 1. Подготовка экземпляра На этом шаге критичными являются несколько факторов, самый изменчивый из них – количество свободного дискового пространства в db-пространствах. При подготовке к миграции на IDS 11 убедитесь, что в db-пространствах, особенно в корневом db-пространстве, достаточно места для преобразования страниц. Объем необходимого пространства зависит от того, с какой версии Informix вы переходите. Чем младше версия, тем больше места необходимо, особенно если версия младше, чем IDS 9.2. С Informix 9.2 IBM поменяла метод хранения индексов по умолчанию – с «attached» на «detached», то есть индексы стали хранится на отдельных страницах, даже если индекс и таблица находятся в одном db-пространстве. При переходе на IDS 9.2 многие заказчики отмечали значительное увеличение объема используемого дискового пространства. Это связано с тем, что страницы, на которых хранились и таблицы, и индексы, теперь стали использоваться только для хранения таблиц. Перед началом обновления я рекомендую иметь не менее 20% свободного пространства в db-пространствах. Эта рекомендация особенно актуальна для корневого db-пространства, где будет проводится много изменений в системных базах данных и будут созданы новые базы. Если вы обновляетесь с IDS 9.4 и старше, то объем доступного пространства не столь критичен, хотя мне вас очень жаль, если у вас меньше 20 Мбайт свободного пространства в корневом db-пространстве и менее 5% в других db-пространствах. Также необходимо убедиться, что у вас много свободного пространства для логических журналов. Я рекомендую иметь 10-15 Мбайт минимум. Если журналы хранятся в корневом db-пространстве, необходимо иметь в этом пространстве минимум 30-35 Мбайт свободного пространства. Вы, возможно, захотите увидеть статистику по текущим запросам в новом окружении, поэтому стоит собрать планы оптимизатора по всем частым запросам, особенно сложным и времязатратным. Для сбора этой информации вы можете выполнить SQL-команду set explain on и выполнить запрос через dbaccess или подобную программу. Если у вас недавняя версия Informix (if you are on more recent version), вы можете использовать модификатор without execute, который позволяет не выполнять запрос, а только подготовить план выполнения. Используя этот модификатор, вы можете запускать запросы DML на промышленных базах без риска повредить их. Кроме просмотра плана оптимизатора при сборе информации о наиболее критичных запросах целесообразно использовать средства мониторинга ОС. Статистические и конфигурационные данные можно собрать с помощью команд dbschema –d –hd и onstat –pr. Команда dbschema генерирует данные о распределении

данных, эти данные используются оптимизатором для формирования планов доступа. Команду можно запускать для всей базы или для отдельных таблиц. Команда onstat читает содержимое служебных страниц корневого db-пространства, на которых хранятся указатели на физические и логические устройства экземпляра, а также данные о бэкапах и некоторые данные по контрольным точкам (checkpoint). Также полезным может быть вывод команд onstat –p/-P, onstat –g iof/iov, onstat –g glo. На уровни ОС полезен вывод утилит vmstat, iostat, sar или других утилит мониторинга ресурсов сервера. Если для архивирования вы используете ON-Bar с или без Informix Server Manager (ISM), не забудьте сделать копии конфигурационных файлов и bootstrap(загрузчик). После завершения всех подготовительных шагов необходимо подготовить данные и создать полный архив экземпляра. Этот процесс включает в себя следующие шаги:

1. Завершение всех транзакций. Самый простой метод – выполнить команды из Таблицы 4.2

Таблица 4.2 Рекомендованный процесс завершения транзакций перед обновлением сервера БД

Команда Описание

onmode –sy/-jy Перевод экземпляра в статический (quiscent) или однопользовательский (если поддерживается) режим и отключение всех (или не-Informix) сессий

onmode -c Принудительное выполнение контрольной точки, очистка памяти от подтвержденных транзакций

onmode -ky Переводит экземпляр в режим off-line

oninit –s/-j Перезапуск экземпляра в статический или однопользовательский (если поддерживается) режим. Во время быстрого восстановления откатываются все открытые транзакции

onmode -l Закрывает открытый логический журнал и начинает писать новфй

2. Удалите все версии таблиц.(in-place table alters) Вопрос версий таблиц мы более подробно рассмотрим в Части 6. Для таблицы можно иметь несколько «версий» ее схемы и данных, в зависимости от типа и частоты изменений структуры таблицы. Во время выполнения обычных операций IDS нормально обрабатывает эти варианты схемы таблицы, но при обновлении они могут представлять проблему. Для выяснения, имеются ли такие версии таблицы для всех баз данных и экземпляров выполните команду oncheck –pT. Часть вывода этой команды для таблицы представляет собой количество строк для разных определений схемы.

Home Data Page Version Summary Version Count 0(oldest) 43946 1(current) 58920 Самый простой метод удаления всех версий таблицы – выполнение псевдо-обновления путем выполнения SQL-команды update table_name set column_name to column_name где table_name – имя таблицы, для которой есть версии, column_name – имя какого-то столбца таблицы 3. Осторожный администратор проверит целостность данных и индексов в базах

данных командами oncheck –cd, oncheck –ci (или даже командами oncheck –cD и oncheck –cI (заглавная буква «i» )). В зависимости от размера баз такая проверка может занять длительное время. Вы можете пропустить этот шаг, если у вас не было повреждений данных или индексов или сбоев устройств хранения

4. Остановите все репликации (ER,HDR) 5. Сделайте по крайней мере один архив 0-го уровня экземпляра. Я обычно делаю два 6. Остановите экземпляр(-ы) Шаг 2. Установка новой версии сервера БД Подробно процесс установки мы обсудим дальше в этой части. Я рекомендую устанавливать новую версию IDS в отдельный каталог. Шаг 3. Переустановка переменных окружения Как вы помните из Части 3 перед запуском экземпляра IDS необходимо установить три переменных окружения: $INFORMIXDIR,$ONCONFIG,$INFORMIXSERVER. Если вы перенесли файл $SQQLHOSTS или хотите, чтобы все экземпляры IDS на этом сервере использовали один файл $SQQLHOSTS, установите переменную $INFORMIXSQLHOSTS. Рекомендуется скопировать $SQQLHOSTS и $ONCONFIG из старой инсталляции в новую. В этом случае вам будет достаточно установить переменную $INFORMIXDIR и проверить, чтобы в $PATH был указан путь к каталогу bin новой инсталляции Шаг 4. Перезапуск экземпляра После выполнения для перезапуска экземпляра команды oninit начнется процесс преобразования к IDS 11. я настойчиво рекомендую мониторить работу экземпляра во время выполнения этого процесса. Поэтому перед запуском экземпляра выполните команду tail –f для лог-файла экземпляра. Для Windows-версии откорйте командное окно экземпляра и выполните команду onstat –m –r 2. После запуска мониторинга, выполнив команду oninit –sv (статический режим) или oninit –jv, переведите экземпляр в статический (если выполняется первый шаг двухступенчатого обновления) или однопользовательский режим. В логе вы увидите сообщения о процессе преобразования. Шаг 5. Проверка целостности данных и создания архива нового экземпляра. Предположим, что в лог-файле (путь к нему определяется переменной MSGPATH) нет записей об ошибках конвертирования. Тогда необходимо подготовить экземпляр к работе, выполнив следующие операции:

1. Обновить статистику оптимизатора. Для базы sysmaster необходимо выполнить команду update statistics high. Для пользовательских баз выполнить update statistics low drop distributions, а затем update statistics.

2. Проверить целостность данных и индексов в базах данных командами oncheck –cd, oncheck –ci (или даже oncheck –cD, oncheck -cI). Если у вас никогда не было повреждения индексов и данных или сбоев устройств хранения, то этот шаг опционален.

3. Создать по крайней мере один архив 0-го уровня Если произошла критическая ошибка, и вам необходимо откатиться на более раннюю версию, то это можно сделать двумя путями. В IDS есть реверсная функция (reversion function). Полное описание этой функции смотрите в IBM Informix Dynamic Server Migration Guide. Я предпочитаю переустановить значения переменных окружения и выполнить полное восстановление. Я рекомендую этот подход не потому, что реверсивная функция не работает - она работает. Но, выполнив восстановление, я знаю, что данные находятся в логически целостном состоянии. Полное восстановление занимает больше времени, но я предпочитаю перестраховаться дважды. Новая установка Новый мастер развертывания IDS и «тихий» (silent) инсталлятор дают вам возможность выбрать компоненты IDS при установке. Используя этот функционал, вы можете установить только базовый функционал сервера (размер составляет 78-112 Мбайт в зависимости от используемого аппаратного сервера и ОС) или выполнить полную установку (требуется около 300 Мбайт). В IDS 11 IBM стандартизировала интерфейс инсталлятора, и процесс установки теперь выглядит одинаково для различных платформ. Вы можете запустить инсталлятор, написанный на Java, в одном из трех режимов:

«тихий» режим (silent mode). Не требует от пользователя ответов на вопросы и не позволяет конфигурировать инсталляцию. Для выполнения такой установки используется .ini файл

консольный режим. Выполнение установки из командной строки. Позволяет конфигурировать инсталляцию

графический режим. Для управления процессом установки используется графический интерфейс.

Используя эти три режима, вы можете установить компоненты IDS как пакет (bundle) или продукт. При пакетной инсталляции вы можете установить все продукты – Informix Dynamic Server, IConnect, CSDK (Client Software Developer Kit – пакет разработчика программ) и т.д – одной командой (ids_install для UNIX/Linux, setup.exe для Windows, .dmg файл для Mac OS X). Этот режим дает возможность вам управлять выбором программ для инсталляции, но так обычно не делается, а выполняется установка продукта. Вы можете «записать» установку пакета для использования файла ответов для «тихой» инсталляции. Мы вернемся к этому вопросу чуть позже. Для Linux/UNIX продукт распространяется как tar файл, который вы можете распаковать и выполнить отдельную инсталляцию IDS (installserver), CSDK (installclientsdk) и т.д. В консольном и графическом режиме установки продукта (product-level installation) есть дополнительный параметр «записи» параметров установки в отдельный файл, с помощью которого вы потом можете установить продукты на произвольное количество компьютеров без ручного проведения процесса установки. При использовании установки пакета (bundle installation) нет возможности записать инсталляцию, но вы можете самостоятельно создать конфигурационный файл для

тихой установки пакета. К сожалению, на данный момент времени этот процесс не автоматизирован. Вам необходимо скопировать и отредактировать файл bundle.ini, который находится в корневом каталоге распакованного дистрибутива IDS. на Mac OS X вы можете скопировать этот файл из каталога $INFORMIXDIR после установки сервера БД. В большинстве случаев для каждой опции есть две возможности – устанавливать или нет. Например, две последующие команды соответственно отменяют установку CSDK и подтверждают установку библиотек восточно-европейских языков Global Language Support (GLS). -P csdk.active=false -SP SERVER/IIF.jar IDS-EASTEURO.active=true Подробно мы рассмотрим эти файлы позже. Установка шаг за шагом. Процесс инсталляции довольно прямолинейный. Единственная тонкость -для инсталляции необходимо использовать права суперпользователя. На MAC OS X, если вы не вошли в систему как root, вам будет предложено ввести пароль администратора. Для MAC OS X установка под User ID не-root пользователя является предпочтительной. Для версий под UNIX/Linux после распаковки дистрибутива перейдите в режим суперпользователя (root) и для запуска установки в графическом режиме запустите команду ids_install –gui Вне зависимости от ОС, для которой вы выполняете установку, будет запущен инсталлятор, который предоставит возможность почитать замечания по выпуску (release notes) и руководство по установке. Сейчас вам стоит изучить замечанию по выпуску, особенно раздел machine notes, где вы найдете рекомендации по настройке ядра для запуска IDS. Для корректной работы IDS вам стоит использовать предложенные настройки. Методы настройки ядра зависят от используемой ОС. Практически во всех случаях вам будет необходимо перезагрузить сервер, чтобы эти настройки вступили в силу. Следующие два окна приветствуют вас и предлагают почитать лицензионное соглашение. Затем появляется окно, где необходимо указать путь, куда будет установлен сервер. Если перед запуском инсталлятора вы установили переменную $INFORMIXDIR, то ее значение будет прочитано инсталлятором и внесено в это поле автоматически. Стандартный путь установки - /opt/IBM/informix. На Mac OS X IDS по умолчанию устанавливается в каталог /Applications/IBM/Informix. Вы можете установить Informix в этот каталог, в подкаталог IDS11 или в структуру каталогов /opt. Каждый вариант имеет преимущества и недостатки. Если вы используете каталог установки по умолчанию – то следуете стандарту ОС. С другой стороны я рекомендую для облегчения обновления и миграции ставить каждый релиз Informix в отдельный каталог. При установке в каталог /opt вы не следуете стандарту ОС, но если сопровождаете инсталляции под разные UNIX-подобные ОС, то можете написать скрипты администрирования, указав одинаковые пути к утилитам Informix на всех платформах. Выбирать вам и выбор зависит от того, что важнее для вашей организации.

После этого вы увидите экран, где сможете выбрать установку всех продуктов и модулей (по умолчанию) или специфицировать установку. В примере положим, что вы устанавливаете все – Client SDK (сюда включен IConnect), IDS и драйвер Informix JDBC. Выбор типа установки «Custom» подразумевает, что вам необходимо определить устанавливаемые модули Informix. Если вы выбрали «Custom»-установку , то увидите окно, в котором сможете указать, какие модули необходимо установить. При выборе модуля в правой части окна будет приведено описание модуля и объем занимаемого им пространства на жестком диске. Большинство основных модулей имеет по крайней мере один или два уровня вложенности опций. Например, для ON-Bar доступны такие опции – интерфейс Informix к Tivoli Storage Manager и Informix Storage Manager. Для CSDK и IСonnect тоже доступен набор различных модулей и опций. После того, как сделаете выбор, нажмите Next, и перед вами появится окно, которое спросит, хотите ли вы включить «разделение ролей». Разделение ролей -это опция, которая не требуется для корректной работы сервера БД. Если вы выберите эту опцию, инсталлятор назначит административные функции, связанные с аудитом и Label Based Access Control (LBAC) соответствующим пользовательским учетным записям. Только те, кто будет залогинен под этой учетной записью, смогут выполнять соответствующие функции. Эта опция полезна в окружении, где на первом месте стоит безопасность. Я ее никогда не использовал. Если вы установите сервер без разделения ролей, а в дальнейшем эта возможность вам понадобится, то в версиях для UNIX/Linux/Mac OS вы можете ее добавить, а на Windows потребуется переустановить сервер и переконфигурировать экземпляр. Если вы выберите установку с разделением ролей, то вам будет предложено ввести имена групп аудита и безопасности. Члены этих групп будут выполнять функции Database System Security Officer (DBSSO) и Auditing Analysis Officer(AAO). В Таблице 4.3 приведено описание этих двух ролей безопасности

Таблица 4.3 Группы разделения ролей

Роль Описание

Auditing Analysis Officer (AAO)

Члены этой группы могут включать и выключать аудит экземпляра и просматривать журналы аудита

Database System Security Officer (DBSSO)

Члены этой группы являются администраторами безопасности экземпляра, они контролируют доступ для других ролей. Например, DBSSO определяет маски аудита, которые может использовать член группы AAO. Таким образом, DBSSO определяет, что подлежит аудиту, а что нет. ААО просто отслеживает процесс аудита.

Рекомендуется, чтобы пользователи root и Informix не были членами этих ролей. Указанные вами группы должны существовать в ОС, и в их составе должен быть хотя бы один участник.

Вне зависимости от того, включите вы или нет разделение ролей, следующее окно предложит вам создать «демонстрационный экземпляр». Эта возможность гораздо более полезная, чем вы можете предположить. Если вы выберите установку демонстрационного экземпляра, инсталлятор предложит вам использовать файл $ONCONFIG по умолчанию, указать путь к уже подготовленному вами файлу или позволить инсталлятору самостоятельно сконфигурировать и настроить экземпляр на основе ваших ответов на несколько вопросов. Если у вас есть уже файл $ONCONFIG, вы можете использовать его и инициализировать экземпляр со всеми необходимыми параметрами (память, пулы буферов, блокировки, устройства архивирования). Если вы решите использовать стандартный файл или разрешите инсталлятору настроить экземпляр, перед вами появится окно, где вам нужно будет ввести базовую информацию для инициализации экземпляра (имя и номер сервера, путь к корневому db-пространству, размер этого пространства). Будьте внимательны, по умолчанию размер корневого db-пространства (ROOTSIZE) составляет несколько сотен мегабайт. Это очень много, достаточно будет 60-80 Мбайт. Если вы выбрали конфигурацию экземпляра инсталлятором на основе оценки нагрузки, вам будет предложено определить количество создаваемых виртуальных процессоров (ВП), объем используемой памяти и предполагаемое количество запросов OLTP и DSS(OLAP). Инсталлятор используем эту информацию для создания экземпляра. Следующее окно показывает итоговый выбор устанавливаемых продуктов и занимаемый ими объем дискового пространства. Во время установки инсталлятор выводит прогресс ее выполнения на экране. После завершения установки инсталлятор выводит окно, где отображен путь к документации и рекомендациям по дальнейшей настройке экземпляра. Демонстрационный экземпляр может инициализироваться неудачно. Причина этого – отсутствие поддержки ядром параметров, необходимых для работы IDS. это справедливо для IDS под Mac OS X.

Репликация установки на несколько физических серверов. Вы установили продукт на один сервер, но вам необходимо установить его на n физических серверов и вы хотите, чтобы все установки были одинаковы? Лучший путь достижения этой цели – тихая установка с файлом ответов. Этот тип установки также требует привилегий супер-пользователя. Если вы выполняете установку на уровне продукта (product-level install) в текстовом или графическом режиме, то можете «записать» ваш выбор добавив опцию –record filename.ini к команде установки. Выходной файл содержит true или false для каждого выбранного модуля. Для тихой инсталляции пакета (silent bundle install) вы должны скопировать и отредактировать файл bundle.ini. Этот файл содержится в корневом каталоге распакованного дистрибутива или в каталоге $INFORMIXDIR (для Mac OS X) Форматы файлов идентичны. После создания или редактирования файлов вы можете повторить установку выполнив такие команды: Пакетная установка (bundle install) ids_install –silent –options filename.ini [другие параметры] Инсталляция продукта (только IDS) Installserver –silent –options filename.ini [другие параметры]

Если в файле ответов вы не указали принятие лицензии, то для тихой установки вам потребуется добавить специальный флаг в командную строку инсталлятора. После установки (пакета или отдельного продукта) последующая конфигурация (добавление db-пространств, перемещение и изменение размера журналов, создание баз данных и таблиц) может осуществляться скриптами. Изменение установки Если после завершения установки вам потребовалось добавить какие-то модули, вы можете просто запустить инсталлятор еще раз и выбрать необходимые модули, которые будут добавлены к вашей установке или удалены из нее. При этом не происходит повторной инсталляции всего продукта. Работает это так. При инсталляции создаются контрольные файлы, в которых записано, какие модули и файлы устанавливались. Когда вы выбираете установку или удаление модулей, мастер просматривает эти контрольные файлы, чтобы определить, какие модули и файлы необходимо установить или удалить. Контрольные файлы также используются для проверки зависимостей пакетов и верификации корректности удаления продукта. Для версий под UNIX/Linux/Mac OS X контрольные файлы находятся в каталоге $INFORMIXDIR/etc. Это файлы manifest.inf, IIFfile, IIFfiles.installed. Эти файлы нельзя изменять. В Windows эта же информация содержится в библиотеках установщика. Файл manifest.inf содержит информацию о установленных модулях, их размере и дате установке, а также некоторые метаданные о функционале модулей. Файлы IIFfiles и IIFfiles.installed одинаковы по формату, но различны о содержимому. Файл IIFfiles содержит список всех файлов сервера IDS. Файл IIFfiles.installed содержит список только установленных файлов. Все описанные файлы обновляются всякий раз, когда вы выполняете операции установки/удаления компонентов. Удаление В отличие от инсталляции, где вы можете выбирать между уровнями продукта и пакета, деинсталляция производится только на уровне продукта. В Windows вы можете выбрать пункт деинсталляции в программной группе Informix или выполнить Control Panel > Add/Remove Software (Панель управления ->Установка и удаление программ). Вы можете удалить все, в том числе db-пространства и чанки, или удалить только IDS и соответствующие двоичные файлы. В Linux/UNIX/Mac OS X в каталоге $INFORMIXDIR содержатся директории деинсталляции CSDK, IDS, JDBС – uninslall_csdk, uninstall_ids nnnn (nnnn – номер версии сервера), jdbc/_uninst. В каждом каталоге находится файл .jar, который выполняет удаление продукта. Пример вызова: java -jar $INFORMIXDIR/uninstall_dir/uninstall.jar по умолчанию деинсталляция осуществляется в консоли. Если хотите видеть графический интерфейс, добавьте в вызов флаг –swing. Для деинсталляции только сервера есть и другой графический интерфейс. В каталоге $INFORMIXDIR вы можете найти файл uninstallserver , выполнив который с флагом –gui вы удалите сервер в графическом режиме. Флаг –silent позволяет удалить продукт без всякого взаимодействия с пользователем. Конфигурационные параметры

Для правильной настройки IDS очень важно понимать назначение различных параметров файла $ONCONFIG и их влияние на функционирование экземпляра. За годы разработки IDS стал практически полностью самонастраивающися сервером (автономный по терминологии IBM). Сегодня вы можете изменять почти все параметры файла $ONCONFIG без перезапуска экземпляра. Те, которые требуют перезапуска, обычно не являются широкоиспользуемыми или настраиваются только один раз. Многие параметры, которыми пользовались администраторы IDS ранее, теперь не используются, например, длительность контрольной точки. Алгоритм обработки контрольных точек полностью поменялся. В IBM Informix Dynamic Server Administrator’s Reference приведено полное описание параметров файла $ONCONFIG. В этом разделе я опишу основные параметры. Я объединил их в логические и функциональные группы. В большинстве случаев внутри логической группы параметры упорядочены по алфавиту, исключение сделано только там, где необходим специальный порядок для понимания взаимосвязи нескольких параметров. Некоторые параметры используют полный путь к определенным файлам или каталогам. Путь по умолчанию в большинстве случаев не соответствует вашему окружению. Поэтому убедитесь, что вес необходимые пути установлены корректно. При установке путей параметров вы должны использовать полные пути. В IDS 11 некоторые параметры, включая ALARMPROGRAM, JVPCLASSPATH, JVPHOME, JVPJAVAHOME, JVPPROFILE, SYSALARMPROGRAM теперь поддерживают возможность установки путей относительно каталога $INFORMIXDIR. Например, теперь JPVHOME можно установить двумя путями JVPHOME /opt/IBM/Informix/11/extend/krakatoa JVPHOME $INFORMIXDIR/extend/krakatoa В случае, если в значении параметра может быть указано несколько путей, например в JVPCLASSPATH,относительный путь справедлив только для первого выражения в строке. Например, установка значения JVPCLASSPATH JVPCLASSPATH $INFORMIXDIR/extend/krakatoa/krakatoa.jar: $INFORMIXDIR/extend/krakatoa/jdbc.jar будет развернута в следующую(неработающую) строку /opt/IBM/Informix/11/extend/krakatoa/krakatoa.jar: $INFORMIXDIR/extend/krakatoa/jdbc.jar перед началом обсуждения различных параметров файла $ONCONFIG вам следует знать, что в IDS 11.5 структура файла была изменена. Раньше параметры в файле располагались практически бессистемно, сейчас все параметры, отвечающие за одну возможность, сгруппированы вместе. Перед началом каждой группы приведено описание группы и допустимые значения параметров. В некоторых случаях приведены рекомендации по установке значений параметров. Эти комментарии ожидались очень давно и должны помочь новичкам корректно настроить IDS. При создании конфигурационного файла экземпляра рекомендуется скопировать файл $INFORMIXDIR/etc/onconfig.std и переименовать его. Я обычно добавляю к имени файла после точки(.) аббревиатуру имени экземпляра. Например, onconfig.sar, onconfig.tag, а затем редактирую файл.

Начальные устройства Параметры этой группы являются физической основой экземпляра. В большинстве случаев если один из параметров этой группы установлен неправильно или соответствующий элемент поврежден, процесс быстрого восстановления прервется , и экземпляр не инициализируется. О быстром восстановлении мы поговорим во второй книге. LOGFILES Этот параметр определяет количество логических журналов, создаваемых во время процесса инициализации. Логические журналы, создаваемые во время инициализации, хранятся в db-пространстве ROOTNAME, которое обычно называется «rootdbs». Логический журнал используется сервером для записи изменений данных (кроме простых BLOB’ов, хранящихся в BLOB-пространствах ) в базах данных со включенным логированием. В зависимости от приложения и количества ользователей вам, возможно, понадобится изменять размер и количество логических журналов. Для инициализации экземпляра достаточно установить LOGFILES равным 6, а LOGSIZE (см. ниже) 2 Мбайт. В части 5 показано, как переместить логические журналы в другое db-пространство и изменить их размер после инициализации экземпляра. LOGSIZE Определяет размер по умолчанию логических журналов экземпляра. Логические журналы используются при инициализации. Я устанавливаю размер корневого db-пространства (ROOTSIZE) равным 60-80 Мбайт, а LOGSIZE 2000 Кбайт. После инициализации экземпляра вы можете удалить исходные логические журналы и создать новые с требуемым размером. Если вы используете BLOB-объекты, размер логических журналов должен быть больше. MIRROR Включает или отключает зеркалирование экземпляра средствами IDS. вы можете установить значение этого параметра равным 1 (включено) во время инициализации экземпляра и использовать зеркалирование, когда в нем возникнет потребность. Или можете оставить значение параметра равным 0 (отключено), а затем динамически включить зеркалирование без необходимости перезапуска экземпляра. MIRROROFFSET Используется, если применяется зеркалирование средствами IDS. смотрите ниже замечания про ROOTOFFSET MIRRORPATH Применяется только при использовании зеркалирования IDS. Параметр определяет полный путь к зеркалу корневого db-пространства. Информация о зеркальных копиях других чанков и db-пространств хранится в зарезервированных страницах экземпляра. Вы можете изменить местонахождение зеркальной копии, но это сделать не так просто: недостаточно просто изменить значение этого параметра и перезапустить экземпляр. Сначала необходимо остановить зеркалирование корневого db-пространства и создать новое место зеркалирования (create new mirror location). Остановите экземпляр и измените значение этого параметра на путь к новому месту зеркалирования. Запустите экземпляр в в статическом режиме (quiescent mode) и включите зеркалирование корневого db-пространства. Когда зеркальная копия синхронизируется, можете перевести сервер в режим он-лайн. Изменение режимов работы сервера, использование утилиты onspaces или SQL API для создания/удаления зеркал рассмотрены в части 5 и 6. Обратите внимание,

что Informix не требует указания размера зеркального чанка. Сервер полагает, что зеркальный чанк будет такого же размера, как и первичный чанк. PHYSDBS Определяет имя db-пространства, в котором хранится физический журнал. По умолчанию физический журнал хранится в корневом db-пространстве. При инициализации экземпляра он может находится только в корневом db-пространстве. В IDS 11 есть возможность изменить место хранения физического журнала без прерывания работы экземпляра. Естественно у этой возможности есть некоторые ограничения. Работу с физическим журналом мы рассмотрим в Части 5. PHYSFILE Определяет размер физического журнала. Я рекомендую установить начальный размер физического журнала в диапазоне 10-15 Мбайт. После создания db-пространств вы можете изменить размер физического журнала. В IDS 11 был внедрен новый алгоритм обработки контрольной точки, поэтому желательно, чтобы размер физического журнала составлял 110 процентов размера буфера. В части 5 показано, как менять размер физического журнала и как перенести его в другое db-пространство. ROOTNAME Содержит имя db-пространства, которое считается корневым. Принято, что корневое db-пространство называется «rootdbs», но вы можете использовать любое имя. При инициализации корневое db-пространство состоит из одного чанка (Allocation of disk space for this dbspace during instance initialization process occurs at a single-chunk level), после инициализации вы можете добавить необходимое количество чанков. ROOTOFFSET Если вы используете сырые устройства или один выделенный файл, то использование смещения дает возможность создавать несколько db-пространств (или чанков) на одном дисковом разделе или в этом файле. На сегодняшний день из-за облегчения работы с дисковыми разделами смещения практически не используются. Смещения внутри файла не используются, поскольку гораздо проще создать еще один файл. При создании db-пространств этот параметр указывают равным 0. Параметр ROOTOFFSET применяется для указания смещения корневого db-пространства. Поскольку именно корневое db-пространство создается первым, то, вероятно, нет необходимости задавать ему какое-либо смещение. Смещения чаще всего используются на Informix под UNIX/Linux, где применяются сырые устройства. Смещения могут быть полезны при необходимости создать несколько маленьких чанков из большого физического раздела. Используя значение смещения вы можете отметить начало чанка на диске. Чанк будет увеличен до требуемого размера и использован для создания нового db-пространства или добавления в существующее db-пространство. Использование смещений требует профессионализма. Сервер не проверяет эксклюзивность смещений и путей к устройствам. В результате можно некорректно указать значение смещения, в результате два устройства пересекутся, и данные будут повреждены. Когда я использовал смещения, то никогда не располагал чанки вплотную друг к другу, а всегда оставлял между ними 1 Мбайт незанятого пространства. ROOTPATH Определяет полный путь к первому чанку корневого db-пространства. Обычно используют полный путь, но можете использовать и относительный путь. Например, я использую такую переменную окружения:

export DEVICES=/opt/IBM/Informix/devices/tagus Тогда можно корректно задать ROOTPATH ROOTPATH $DEVICES/root_space ROOTSIZE Определяет размер в килобайтах первого чанка корневого db-пространства. Я рекомендую выделять 60-80 Мбайт. Этого значения достаточно для инициализации экземпляра -создания логического и физического журнала и системных БД. После инициализации рекомендуется перенести журналы в другое db-пространство (см Часть 5). В корневом db-пространстве могут создаваться временные таблицы для сортировки и упорядочения результатов выборки, но размер этих таблиц невелик. Для хранения временных таблиц лучше создать временные db-пространства. Если вы не планируете создавать временные db-пространства, добавьте к корневому db-пространству дополнительные чанки. Временные db-пространства мы обсудим в части 5. System configuration Параметры этой группы также влияют на поведение всего экземпляра. Здесь устанавливается допустимое количество пользовательских соединений, протоколы, по которым можно подключиться к серверу, количество ВП, максимально допустимое время между обработками контрольной точки. При настройке производительности многие администраторы первым делом вспоминают о параметрах разделяемой памяти. Однако, многие параметры, которые мы рассмотрим ниже, могут серьезно повлиять на производительность экземпляра. Во время настройки экземпляра их нужно конфигурировать также внимательно, как и параметры разделяемой памяти. ALARMPROGRAM Определяет полный путь к программе или скрипту, которые будут запущены сервером БД при наступлении некоторого события. Программа или скрипт должны уметь принимать 5 аргументов – важность события (termed severity), идентификатор класса (class ID), сообщение класса (class message), особое сообщение (specific message) и ссылку на файл «смотреть также» («see also» file reference). Каждое событие может иметь свою схему уведомления администратора или процедуру автоматического разрешения события. Для обработки специфических событий эту программу можно сконфигурировать на вызов других утилит. В каталоге $INFORMIXDIR/etc есть несколько файлов-шаблонов с программами обработки специфических событий: в зависимости от версии ОС это могут быть файлы logs_full.sh, no_logs.sh или logs_full.bat, no_logs.bat. эти скрипты предназначены для обработки только одного события. Первый скрипт (logs_full) с помощью набора утилит ON-Bar автоматически архивирует файлы логического журнала, второй вообще ничего не делает. Я рекомендую не изменять этот параметр и использовать существующий скрипт. AUTO_AIOVPS Этот параметр разрешает серверу управлять количеством виртуальных процессоров асинхронного ввода/вывода, которые обслуживают ввод/вывод логического и физического журнала, файловых чанков и т.п. Включение этого функционала не приводит к ухудшению производительности, но может ее улучшить. Рекомендую установить параметр AUTO_AIOVPS равным 1 (включено)

AUTO_CKPTS Разрешает серверу БД при необходимости выполнять обработку контрольной точки для достижения требуемого времени восстановления. Включение этого функционала не приводит к ухудшению производительности, но может ее улучшить. Рекомендую установить параметр AUTO_CKPTS равным 1 (включено) AUTO_LRU_TUNING Разрешает серверу БД автоматически управлять временем очистки последних использованных запросов (least recently used queues). Эта возможность представляет еще одно усовершенствование системы управления буферным пулом, представленной в IDS 9.4. Когда экземпляр считает, что необходимо провести чистку, то процесс очистки буферов получает высший приоритет. Включение этого функционала не приводит к ухудшению производительности, но может ее улучшить. Рекомендую установить параметр AUTO_LRU_TUNING равным 1 (включено) CKPTINTVL Устанавливает максимальное количество секунд между обработками контрольной точки в том случае, когда экземпляр обрабатывает пользовательские потоки (if the instance is handling user threads). Запись на диск во время обработки контрольной точки – самый эффективный вид записи. В IDS 11 был введен новый алгоритм обработки контрольной точки, поэтому этот параметр несколько утратил свое значение (is now more a worst-case trigger than a hard system limit to which you must manage). Оставьте его равным 300 секунд. CLEANERS Определяет количество потоков-чистильщиков страниц при запуске экземпляра. IDS использует чистильщики для передачи данных из буферного пула в механизм записи на диск. Разработчики IDS рекомендуют выделять один чистильщик на каждый активный диск экземпляра. Максимальное значение этого параметра равно 128. CONSOLE В последних версиях IDS этот параметр практически бесполезен. Да и раньше ситуация была не намного лучше – на консоль выводились сообщения, что логические журналы заполнены и необходимо их архивировать, но это и так было видно, поскольку экземпляр прекращал операции до архивирования журнала. Я обычно устанавливаю этот параметр равным /dev/null или NUL. Вы можете перенаправить вывод сообщений в файл (по умолчанию так сделано в Windows-версии IDS). DBSERVERNAME Назначает экземпляру уникальное имя среди всех экземпляров IDS в сети. Максимальная длина имени составляет 128 символов. Это имя регистрочуствительное. Нельзя использовать заглавные буквы, пробелы, знаки табуляции, тире, дефис, символ @. Это имя также используется в качестве переменной окружения $INFORMIXSERVER и записывается в первое поле файла $SQLHOSTS. Имя экземпляра и псевдонимы (см. ниже) должно соответствовать правилам именования объектов в вашей организации. В книге в качестве имен экземпляров используются названия рек. DBSERVERALIASES В этом параметры содержится псевдоним (псевдонимы) экземпляра. Обычно псевдонимы используются для задания дополнительных путей подключения к экземпляру. Длина псевдонима равна 128 символам, псевдоним является регистрочувствительным и должен быть уникальным в сети. Строки подключения к экземпляру обычно связаны с

протоколом подключения, поэтому желательно, чтобы псевдоним отражал этот факт. Например, чтобы обеспечить подключение через вторую сетевую карту по TCP/IP к экземпляру sarthe, в DBSERVERALIASES я запишу псевдоним sarthe_tcp_2. Чтобы псевдонимы соединений работали, они должны быть также записаны в файл $SQLHOSTS и в файл /etc/services или его аналог. Когда я говорю, что параметр DBSERVERALIASES используется для соединений по сети, то это не так, если вы используете Enterprise Replication MACH-11. Более подробно конфигурация ER MACH-11 будет рассматриваться в следующей книге. DBSPACETEMP Содержит имена db-пространств, которые используются для сортировки, упорядочения, хранения временных таблиц, хэш-индексов и т.п. Введенные имена должны быть разделены двоеточиями или запятыми без пробелов между ними. Вместе с разделителями максимальная длина этого параметра составляет 254 символа. Db-пространства, указанные в параметре DBSPACETEMP могут быть созданы и как обычные db-пространства, и как «временные» db-пространства, но всегда используются как временные db-пространства. Я рекомендую использовать именно временные db-пространства, поскольку работа с временными db-пространствами не регистрируется в логическом журнале. Временные пространства могут иметь страницу любого размера, но все временные пространства должны иметь страницу одинакового размера. В большинстве окружений при создании временных db-пространств используется размер страницы по умолчанию всего экземпляра. Во время инициализации вы можете ввести имена временных db-пространств, которых еще не существует. В этом случае в файл MSGPATH будет записано сообщение об ошибке, которое говорит о том, что невозможно найти эти db-пространства. Это сообщение будет повторяться всякий раз при запуске экземпляра до тех пор, пока вы не создадите временные db-пространства, имена которых указаны в параметре DBSPACETEMP. В качестве временных db-пространств используются только db-пространства, чьи имена указаны в параметре DBSPACETEMP или в переменных окружения $DBSPACETEMP, $PSORT_TEMP В IDS 10 был существенно переработан механизм использования временных db-пространств, и сейчас они используются значительно реже. За этот функционал отвечает параметр NON_PDQ_QUERY_MEM, и он подробно рассматривается во второй книге. DIRECT_IO Если вы используете Informix под UNIX/Linux и ваша ОС поддерживает прямой файловый ввод/вывод, и вы используете чанки на файлах (выделенные файлы), то для ускорения доступа к чанкам можете установить этот параметр равным 1. Если ядро ОС поддерживает асинхронный ввод/вывод (kernel asynchronous IO - KAIO), и он включен в экземпляре, то при конфигурировании экземпляра вы можете уменьшить количество ВП асинхронного ввода/вывода (AIO VP). Более подробную информацию по этим вопросам смотрите в machine notes вашего дистрибутива. MSGPATH В этом параметре хранится путь к журналу событий экземпляра. В журнал записываются все сообщения экземпляра об ошибках. Каждый экземпляр на физическом сервере должен иметь свой собственный журнал. Я обычно создаю отдельный каталог, где хранятся все журналы ошибок. Обычно к имени журнала я прибавляю имя экземпляра, но вы можете

использовать любое приятное вам имя. Например, для экземпляра sarthe параметр MSGPATH имеет следующее значение: MSGPATH /opt/IBM/Informix/logs/sarthe.log С течением времени размер этого файла увеличивается, поэтому файл необходимо периодически архивировать и чистить. NETTYPE От установки этого параметра зависит не только количество пользователей, которые могут подключиться к экземпляру, но и то, как они могут подключиться. Для обслуживания подключений к экземпляру используется понятие нити опроса и нити прослушивания (poll thread, listen thread) .Нить опроса прослушивает сообщения клиентских подключений и передает их нити прослушивания, которая производит аутентификацию пользователя и производит подключение пользователя к экземпляру путем запуска потока «sqlexec» для обработки SQL-команд. Результат выполнения команды передается в обратном порядке. Нить опроса запускается для каждой уникальной комбинации NETTYPE-параметров. В версиях для UNIX/Linux/Mac OS параметр NETTYPE позволяет также определить, ВП какого класса (CPU или NET) используются для обработки отдельной нити опроса. Соединения через разделяемую память обрабатываются нитью, которая использует ВП класса CPU, а другие типы соединений могут обрабатываться ВП класса NET. Если для обработки подключений вы попробуете выделить больше ВП класса CPU, чем общее количество ВП класса CPU, то экземпляр выделит ВП класса NET. Поля параметра NETTYPE представлены в таблице 4.4.

Таблица 4.4 поля параметра NETTYPE

Номер поля

Имя поля Возможные значения (зависят от версии ОС)

1 Протокол подключения (connection protocol)

ipcshm, tlitcp, soctcp, tlispx, tlidr, socdr, sqlmux, tliimc, socimc, socssl

2 Потоки (threads) Количество запускаемых нитей

3 Пользователи (users) Количество пользовательских подключений, которое будет обслуживаться каждой нитью

4 Класс ВП (VP class) Класс ВП, который будет обслуживать эти нити. Может быть CPU или NET

Не забывайте, что необходимо разрешать только необходимые типы подключения. Включение каждого нового типа возможных подключений создает дополнительную нагрузку на сервер. NUMAIOVPS Этот параметр, задающий количество виртуальных процессоров ввода/вывода (AIO ВП) может быть недоступен в версии сервера под вашу ОС. В IDS 11.50 этот параметр больше не используется, вместо него применяется параметр AUTO_AIOVPS.

В более старых версиях IDS ВП AIO используются для обслуживания ввода/вывода из файловых чанков (если не поддерживается прямой ввод/вывод), а также из физического и логического журнала. При использовании IDS 10 и младше, следуйте общим рекомендациям: для операций экземпляра выделяйте три ВП AIO плюс по одному ВП для каждого диска/LUN, на которых располагается один или более чанков. В IDS 11.10 установите в качестве значения NUMAIOVPS значительно меньшее число (set NUMAIOVPS to a much lower number) и установите параметр AUTO_AIOVPS, чтобы экземпляр самостоятельно управлял количеством ВП. В младших версиях IDS для определения количества ВП AIO предпочтительнее использовать параметр VPCLASS. Если вы используете этот параметр – закомментируйте параметр NUMAIOVPS, поскольку он становится избыточным. VPCLASS Этот параметр был введен во время выпуска IDS 9 и является стандартом определения ВП, создаваемых экземпляром. В целях обратной совместимости в файле $ONCONFIG в версиях IDS младше 11.50 оставлены параметры ВП класса CPU, AIO. Правда, синтаксис определения немного поменялся. Используя параметр VPCLASS вы можете определить конфигурируемые пользователем классы виртуальных процессоров. Например, можно определить ВП для шифрования столбцов, интегрированной виртуальной машины Java, DataBlad’ов. Параметр имеет такой формат: vpclass class, num=number, options Для инициализации необходимо определить только ВП классов CPU и AIO. Определение выглядит примерно так: vpclass CPU, num=3 vpclass AIO, num=5 Для инициализации экземпляра нет необходимости использовать дополнительные опции. Информацию о доступных опциях вы можете найти в IBM Informix Dynamic Server Administrator’s Reference. При использовании VPCLASS для создания ВП класса CPU необходимо раскомментировать (comment out) параметры AFF_NPROCS, AFF_SPROC, NOAGE, NUMCPUVPS и, возможно, параметры MULTIPROCESSOR, SINGLE_CPU_VP. При использовании VPCLASS для определения количества ВП AIO в версиях младше IDS 11.50 необходимо раскомментировать (comment out) параметр NUMAIOVPS. Если вы забудете это сделать, инициализация экземпляра завершится ошибкой. К счастью в файл MSGPATH будет записана диагностика ошибки, по которой можно понять, что вам необходимо исправить. Разделяемая память Следующие параметры отвечают за конфигурирование разделяемой памяти экземпляра. BUFFERPOOL Этот параметр введен в IDS 10 и представляет собой объединение отдельных параметров предыдущих версий Informix. Раньше для каждого экземпляра был один набор буферов. В IDS 10 появилась возможность создавать db-пространства с разным размером страниц (до 16 КБайт). Каждый набор db-пространств, имеющих нестандартный размер страницы,

требует пул буферов с таким же размером страницы. IBM предлагает этот параметр для определения пулов буферов с разным размером страницы. Пул буферов выделяется для всех db-пространств с определенным размером страницы, а не для отдельного db-пространства. Сервер БД использует буфера для буферизирования данных запросов чтения и записи. Чем больше у вас буферов, тем больше вероятность, что необходимые пользователю данные находятся в буфере, и нет необходимости в обращении к диску (параметры LRU_MIN и MAX_DIRTY регулируют очистку буферов от устаревших данных). В то же время большое количество буферов может привести к увеличению нагрузки на экземпляр и нерациональному использованию системных ресурсов. Система должна управлять избыточными буферами, проверять их во время обработки контрольной точки. В файле-шаблоне $INFORMIXDIR/etc/onconfig.std для параметра BUFFERPOOL есть две записи. Первая -это «значение по умолчанию», вторая запись – это запись для размера страницы по умолчанию для Informix под вашу ОС. В следующей части вы увидите, как создавать db-пространства с разным размером страницы. Один из методов создания db-пространств автоматически создает и пул буферов для заданного размера страницы, если этот пул еще не существует. Значение по умолчанию из файла $ONCONFIG будет использовано для установки параметров этого пула буферов. Более подробно смотрите следующую часть. Вторая запись BUFFERPOOL должна быть модифицирована перед инициализацией экземпляра. Значение этого параметра сильно зависит от объема физической памяти сервера, количества запущенных экземпляров, количества пользовательских подключений, типа выполняемых операций (простые или сложные) и т.п. Общее правило рекомендует выделять 20-25 % физической памяти сервера экземпляру IDS, но это правило не учитывает рабочей нагрузки, мультирезидентности и других операций, которые система должна поддерживать. Для начала установите значение этого параметра равным 10000, LRU_MIN_DIRTY=70, LRU_MAX_DIRTY=80. А затем мониторьте чтения из кэша и запись в кэш, а также размер физического журнала. Если процент чтений из кэша и записи в кэш не будет сильно падать, то BUFFERPOOL можно установить равным по размеру 110% размера физического журнала. Мониторить эти значения можно вызовом команды onstat –p . Во время нормальной работы БД значение %cache_read должно быть больше 95%, а значение %cache_write должно быть больше 85%. Начиная с IDS 11, сервер на основе мониторинга экземпляра записывает в MSGPATH рекомендации по настройке этого и некоторых других параметров. LOCKS Этот параметр несильно влияет на размер разделяемой памяти экземпляра. Каждая блокировка занимает 44 байта в резидентном разделе разделяемой памяти. Поэтому значение этого параметра устанавливается большим, особенно в OLTP-средах, где недостаток блокировок может привести к падению приложения. Мониторинг блокировок проводится командами onstat –p и onstat –k. Минимальное значение этого параметра равно 2000, максимальное составляет 8000000 для 32-битовых редакций IDS и 500000000 для 64-битовых редакций. Для загруженного экземпляра я устанавливаю значение этого параметра равным 100000 (требует 2-4 Мбайта разделяемой памяти в зависимости от размера страницы по умолчанию), а затем провожу более точную настройку.

В отличие от предыдущих версий Informix, количество блокировок больше не фиксировано. Если экземпляру требуется больше блокировок, чем вы установили в этом параметре, он динамически добавит их, используя виртуальную часть разделяемой памяти. Не полагайтесь на эту возможность, поскольку выделение и освобождение блокировок требует некоторого времени, поэтому старайтесь установить параметр LOCKS как можно точнее. SERVERNUM Используется для задания смещения в структурах общей разделяемой памяти ОС (SHMBASE), откуда будет выделяться память для использования экземпляром. Вы можете установить значение этого параметра равным 0 (ноль), но я рекомендую использовать значение из диапазона 1-255. Это значение должно быть уникальным, если на компьютере будет выполняться более одного экземпляра IDS. Последовательное нумерование экземпляров не требуется, как не требуется и уникальность этого значения в пределах сети – оно имеет смысл только для физического сервера. Я рекомендую делать значение SERVERNUM уникальным во всем окружении; это позволит легче переносить экземпляры между системами без необходимости отлавливать потенциальные конфликты адресов памяти. Хотя если у вас больше 255 экземпляров, это невозможно. SHMTOTAL Определяет максимальный объем разделяемой памяти (в Килобайтах), который может использовать экземпляр. Если экземпляр пытается выделить больше памяти, чем разрешено этим параметром, то приложение, деятельность которого привела к попытке выделения дополнительной памяти, получит сообщение об ошибке, и поток вызвавший эту попытку, будет прибит экземпляром. В журнал MSGPATH будет записано сообщение о попытке выделения памяти. Установка этого параметра равным 0 (ноль)означает отсутствие ограничений на выделение памяти, но устанавливать такое значение параметра необходимо очень хорошо подумав и проводить постоянный мониторинг экземпляра и ОС. SHMVIRTSIZE Определяет начальный размер виртуальной части разделяемой памяти (в Килобайтах). Этот параметр необходимо настраивать в зависимости от нагрузки экземпляра. Я рекомендую начинать со значения 250 Мбайт (262144 КБайт) и затем мониторить экземпляр. Если экземпляру необходима дополнительная виртуальная память, он динамически выделит сегмент размером SHMADD. Вы можете мониторить выделение дополнительных сегментов виртуальной памяти с помощью команды onstat –g seg. С выделением дополнительных сегментов виртуальной памяти, эффективность ее использования снижается. Если во время выполнения нормальных операций с БД происходит выделение дополнительных сегментов виртуальной памяти, необходимо настроить этот параметр. Его значение должно быть суммой всех выделенных объемов виртуальной памяти. Если экземпляр больше не нуждается в дополнительной виртуальной памяти, он должен освободить этот сегмент автоматически. Иногда эта операция завершается неудачно, и тогда необходимо освободить неиспользуемый сегмент виртуальной памяти с помощью команды onmode –F. SHMADD Определяет объем дополнительной памяти (в КБайтах), который будет запрошен экземпляром, если ему не хватило виртуальной памяти, выделенной через параметр SHMVIRTSIZE. Я устанавливаю это значение равным 120 Мбайт (131072 КБайт), а затем мониторю экзмепляр, чтобы выяснить, сколько дополнительно выделенной памяти действительно используется.

Выделение множества дополнительных сегментов виртуальной памяти может негативно сказаться на производительности экземпляра (подробнее этот вопрос мы обсудим во второй книге). С другой стороны выделение сразу большого объема виртуальной памяти, который практически не используется – это просто потеря системных ресурсов. Использование дополнительных сегментов виртуальной памяти можно посмотреть с помощью команды onstat –g seg. EXTSHMADD Контролирует расширения виртуальной части разделяемой памяти (control an extension to the virtual portion of shared memory). Эта часть памяти содержит кучи потоков определенных пользователем ВП и процедур (UDR). В качестве начального значения этого параметра я использую 16 Мбайт (16384 КБайт). Если вы используете DataBlad’ы и UDR, то стоит установить для этого параметра большее значение. SHMVIRT_ALLOCSEG Этот параметр введен в IDS11 и предназначен для определения реакции экземпляра на невозможность выделения памяти. Сервер может послать вам сообщение, что он не может выделить дополнительный сегмент виртуальной памяти. Этот параметр состоит из двух частей. Первая часть определяет пороговое значение объема памяти, ниже которого сервер будет пытаться выделять дополнительные сегменты виртуальной памяти. Значение может быть задано в килобайтах или процентах используемой памяти. Если вы используете значение в процентах, то оно должно быть в диапазоне 0.40-0.99 Вторая часть параметра определяет серьезность предупреждения, которое будет послано SYSALARMPROGRAM, если экземпляр не сможет выделить сегмент объемом SHMADD. В таблице 4.5 приведены возможные значения Таблица 4.5 возможные значения второго компонента параметра SHMVIRT_ALLOCSEG

Значение параметра

Уровень предупреждения, посылаемый SYSALARMPROGRAM

1 Не важно (not noteworthy)

2 Информация (information)

3 Внимание (attention)

4 Серьезно (emergency)

5 Фатальная ошибка (fatal)

Естественно, необходимо проверить, что SYSALARMPROGRAM может корректно отловить и обработать это предупреждение. Например, можно установить этот параметр так: SHMVIRT_ALLOCSEG 50000,3

Это означает, что предупреждение будет послано, если экземпляр имеет менее 50 Мбайт виртуальной памяти и не может выделить больше из-за параметра SHMTOTAL или ограничений ОС. После настройки экземпляра вы можете установить этот параметр, например, так: SHMVIRT_ALLOCSEG .91,4 Что означает посылку сообщения с уровнем серьезности «emergency», если экземпляр имеет менее 9 процентов доступной виртуальной памяти и не может выделить дополнительный сегмент из-за параметра SHMTOTAL или ограничений ОС. Архивирование и восстановление Давайте теперь рассмотрим параметры, которые предназначены для конфигурирования архивирования/восстановления. Некоторые из них относятся к ontape, другие – к набору ON-Bar. В этом разделе я приведу описание только тех параметров, установка которых необходима для запуска экземпляра, т.е. мы поговорим о параметрах утилиты ontape. О параметрах ON-Bar речь пойдет в Части 7. В IDS 11 были внесены существенные изменения в процесс архивирования /восстановления. Одно из них необходимо упомянуть сейчас. В предыдущих релизах параметры LTAPEDEV и TAPEDEV поддерживали запись только на ленту или стандартное устройство ввода/вывода (STDIO), что приводило к необходимости использовать каналы или скрипт оболочки для перенаправления вывода в файл или на устройство архивирования. Хотя была возможность установить в качестве значения этих параметров имя файла, но такой подход был не совсем хорош, поскольку каждая операция архивирования перезаписывала один и тот же файл. Сейчас эта проблема решена. Вы можете установить в качестве значений параметров LTAPEDEV и TAPEDEV путь к каталогу, например, /opt/IBM/informix/backups/ (не забудьте про завершающий «/»). Если вы так сделаете, то ontape будет архивировать экземпляр или логические журналы в этот каталог, и имена файлов будут уникальными. Подробнее эту возможность мы обсудим в Части 7. LTAPEBLK и LTAPESIZE По этим параметрам смотрите ниже замечания к параметрам TAPEBLK и TAPESIZE. LTAPEDEV Определяет устройство, которое будет использоваться для архивирования логических журналов утилитой ontape. Значение по умолчанию этого параметра зависит от платформы. Для версий под UNIX/Linux/Mac OS X это имя файла (generic file name), в версиях под Windows значение по умолчанию установлено в NUL, т.е. архивирование не производится. Вне зависимости от дистрибутива, если вы установите значение этого параметра равным /dev/null, то можете нарваться на два неприятных эффекта. Первый - полное восстановление экземпляра утилитой ontape невозможно, поскольку каждый журнал очищается для повторного использования сразу после заполнения и больше не содержит последнюю контрольную точку или открытую транзакцию. Использованный журнал очищается не сразу и может быть перечитан процессом восстановления, но это кране рискованный трюк. Если журналы с момента последнего архивирования были переписаны, вы сможете восстановить базу только на момент создания последнего архива. Второй побочный эффект – невозможность использовать для архивирования утилиты ON-Bar. Следует отметить, что ON-Bar не считывает этот параметр динамически при выполнении операции архивирования, а использует значение, которое было задано во время старта экземпляра. Поэтому можно изменить этот параметр во время работы

экземпляра с имени устройства на /dev/null, и ON-Bar будет нормально работать. Правда, я не приветствую такой подход. Для промышленных установок при работе с журналируемыми базами данных я всегда рекомендую архивировать логические журналы на диск или ленту. Это позволит вам провести полное восстановление экземпляра в случае критического сбоя. Итак, установите в качестве значения параметра LTAPEDEV ленточное устройство или диск и выполняйте регулярное архивирование логических журналов с помощью ontape или ON-Bar. При начальном конфигурировании экземпляра я устанавливаю значение этого параметра равным /dev/null, а после полной настройки ставлю в качестве его значения имя устройства. TAPEBLK Этот параметр устанавливает размер блока ленточного устройства архивирования (TAPEDEV), используется утилитами ontape, onload, onunload при обработке ввода/вывода этого устройства. Значение по умолчанию можете подходить, а может и не подходить для вашего устройства. В общем, чем больше размер блока устройства, тем быстрее проходят операции архивирования/восстановления. Перед установкой параметра посмотрите документацию к оборудованию. TAPEDEV Параметр указывает на устройство, которое будет использоваться для архивирования экземпляра. Этот может быть полный путь к каталогу, полный путь к файлу, STDIO, символическая ссылка на каталог или устройство. Если вы используете файл, каталог или STDIO, то сервер игнорирует параметр TAPEBLK, но размер файла будет зависеть от параметра TAPESIZE. Можно установить значение этого параметра равным /dev/null, но тогда будет невозможно восстановление экземпляра. Если вы используете другое допустимое значение, включая файл, значение параметра будет проигнорировано ON-Bar с или без ISM. Операции утилиты ON-Bar используют устройства, сконфигурированные с помощью менеджера хранилища (storage manager). TAPESIZE Специфицирует максимальный объем данных (в килобайтах), которые могут быть записаны на ленту или максимальный размер файла-архива при использовании утилиты ontape. В предыдущих версиях IDS этот параметр требовал особого внимания. Раньше, когда указанный объем данных записывался на ленту, вам предлагалось для продолжения архивирования вставить новую ленту. Если в параметре было установлен максимальный объем ленты (например, 2 ГБайт), и лента была некорректно отформатирована (имела меньший объем), то процесс архивирования завершался с ошибкой. Тоже самое происходило с файлом: если он достигал максимального размера в процессе архивирования, то процесс архивирования завершался ошибкой. Практическая рекомендация была такой: в качестве значения параметра использовать 95-97 процентов полного объема ленты. Сейчас в качестве значения этого параметра при архивировании на ленту можно установить 0 (ноль). В этом случае ontape будет писать данные на ленту, пока не получит сообщение «end-of-medium», после чего предложит вставить следующую ленту. В результате вы можете использовать ленты одинакового стандарта, но разной емкости. Если вы делаете архивы в файл или каталог, то значение параметра не должно превышать ограничения на максимальный размер файла в ОС (смотрите Часть7).

Этот параметр не применим к архивам, созданным с помощью ON-Bar для разных менеджеров хранилищ (например, ISM) Первый запуск экземпляра Вы установили переменные окружения, создали устройства, отредактировали файл конфигурации и $SQLHOSTS. Настала пора выполнить первый запуск экземпляра. Полезно просматривать не только вывод команды инициализации, но и файл MSGPATH. Для этого , как пользователь informix, я создаю , с помощью команды touch файл, указанный в $ONCONFIG, устанавливаю права на файл так, чтобы читать его могли все, а затем выполняю команду tail –f. Во втором окне я выполняю команду запуска экземпляра oninit –ivy. Флаг –I приказывает серверу выполнить инициализацию корневого db-пространства, в результате чего из него удаляются все структуры данных, которые могли там остаться от предыдущей инсталляции или прошлой попытки инициализировать сервер. Использовать этот флаг надо с особой осторожностью и только в том случае, если вы хотите начать с полностью чистого экземпляра. Флаг –v предписывает серверу выдавать сообщения о процессе инициализации. Флаг –y показывает, что вы действительно намерены инициализировать сервер и отвечает утвердительно на вопрос в стиле «Are you sure…» Когда экземпляр стартует в первый раз, то в файл MSGPATH выводится много сообщений: статусные сообщения о выделении разделяемой памяти, верифицирующие сообщения об обнаружении физических устройств, сообщения о запуске виртуальных процессоров, установке сетевого соединения (если настроено для экземпляра) и т.д. если все идет хорошо, вы увидите сообщения, что создаются и заполняются системные базы данных (sys). В процессе инициализации создаются четыре системные БД – sysmaster, sysadmin, sysusers, sysutils. Ниже мы рассмотрим эти БД подробнее. Пока запомните, что до тех пор, пока вы не увидите сообщения о завершении создания этих БД, нельзя пытаться выполнять любые команды на экземпляре, в том числе и подключаться к нему. Поэтому очень важно мониторить файл MSGPATH и вывод команды oninit. Если вы попробуете подключиться к экземпляру в момент создания системных баз данных, то с очень высокой вероятностью прервете процесс их создания, и сервер будет полностью неработоспособен. Поверьте, я пару раз такое проделывал, но только на тестовом сервере. Процесс создания системных БД занимает 1-2 минуты. Базы данных Sys Во время инициализации создаются четыре системные БД - sysmaster, sysadmin, sysusers, sysutils. В этом разделе я расскажу об этих БД и о интерфейсе мониторинга системы (System Monitoring Interface - SMI). В зависимости от используемой функциональности в экземпляре могут быть и другие системные ЬД. Например, базы данных syscdr, sysha, onpload. О двух из них я кратко расскажу, а подробное рассмотрение этих баз будет проведено в моей следующей книге. База данных sysmaster и SMI База данных sysmaster и SMI с точки зрения администратора являются двумя прекрасными инструментами. Через интерфейс SMI администратор может получить доступ к информации о всех операциях экземпляра. База данных sysmaster – это комбинация настоящих таблиц, созданных в корневом db-пространстве, и псевдо-таблиц,

управляемых сервером БД. Псевдо-таблицы, создаваемые при запуске экземпляра, являются указателями на разделяемую память для экземпляра IDS. Через интерфейс SMI вы можете с помощью подмножества языка SQL получать данные из настоящих таблиц и псевдо-таблиц БД sysmaster. Утилиты onstat и oncheck также работают через SMI. Схема БД sysmaster находится в файле $INFORMIXDIR/etc/sysmaster.sql. этот файл содержит описание каждой таблицы и полей этих таблиц. Как я уже говорил, этв бд создается во время процесса инициализации. Хотя и есть возможность в любой момент времени пересоздать БД sysmaster, но лучше так не делать – может сильно не повезти. БД sysmaster создана так, что когда она находится в рабочем режиме, для нее невозможно создать схему (a database schema cannot be created) и выгрузить таблицы. Поскольку многие таблицы БД представляют собой указатели на разделяемую память, из этих таблиц нельзя удалять данные, модифицировать их или записывать новые. Члены группы DBSA могут в этой базе создавать хранимые процедуры, которые могут быть вызваны экземпляром или пользовательскими операциями. БД sysmaster создается с небуферизированным журналированием (unbuffered logging). Но при необходимости вы можете перевести ее в режим буферизированного журналирования. Я не рекомендую изменять режим журналирования, посколку выигрыша в производительности не будет или он будет очень невелик. Вы можете выполнять запросы к этой БД через ваше приложение или через dbaccess. Для БД sysmaster, в отличие от обычных БД, нельзя задать привилегии на выборку из таблиц – роль «public» имеет разрешение connect ко всем таблицам. База данных sysmaster функционирует как обычная БД, поэтому вы можете использовать данные из нее для объединения (join) с данными других БД. В отличие от обычных БД выборки или объединения (selects or joins ) с БД sysmaster можно делать даже в том случае, когда другие БД используют разные режимы журналирования. Вы увидите, что в БД sysmaster таблиц немного, но много представлений. В большинстве случаев эти представления служат для обратной совместимости со сторонними приложениями. В последующих релизах эти представления могут быть удалены или изменены. По пводу поддерживаемых в вашей аерсии представлений смотрите официальную документацию дистрибутива. База данных sysadmin В IDS 11 база данных sysadmin для поддержки SQL интерфейса администрирования содержит функции task() и admin(). Также в ней находится таблица истории команд, выполненных этими функциями, и эта БД используется планировщиком для выполнения заданий. В БД также находятся данные о производительности и другие исторические данные (other historical data), имеющие целью помочь администратору в настройке экземпляра. База данных sysusers В этой БД мало таблиц. Она содержит идентификатор пользователя (user ID), роль и хост, с которого выполнено подключение. С помощью этой БД определяется, какие пользователи, группы пользователей и роли могут подсоединяться к экземплярам. Эта БД также используется членом роли DBSECAM для управления безопасностью экземпляра База данных sysutils Эта БД используется набором утилит ON-Bar. В таблицах БД находятся данные о каждом экземпляре, пространствах хранения, архивировании и восстановлении, статусе лент и времени истечения актуальности архива и подобная информация. Эта БД может быть использована для восстановления загрузчика onbar и других критических файлов

База данных syscdr Эта БД создается при включении Enterprise Replication. Содержит определения и правила репликации, определения хостов и другие объекты, связанные с ER. База данных sysha Эта БД появилась в IDS 11 и предназначена для поддержки функционала высокой доступности (high-availability functionality) на основе технологии MACH-11. подробно эта технология будет рассмотрена во второй книге. Заключение В этом разделе приведено много полезной информации. Сейчас вы должны уже хорошо понимать, как установить или обновить IDS и какие опции нужно выбрать во время этого процесса. Вам следует знать наиболее важные параметры файла $ONCONFIG и для чего они предназначены, также необходимо знать предназначение системных БД. Во время установки и инициализации Informix Dynamic Server помните о следующем:

Если вы планируете использовать программную или аппаратную защиту от сбоев дисков, включите зеркалирование (параметр MIRROR). Вы не обязаны использовать зеркалирование. В критических ситуациях вы можете быстро создать зеркала с помощью Informix без необходимости перезапуска экземпляра.

Если вы планируете для архивирования использовать утилиту ontape, убедитесь, что вы выставили правильные конфигурационные параметры. В Части 7 мы подробно поговорим о архивировании и восстановлении экземпляра

Установите размер корневого db-пространства 60-80 Мбайт. Корневое db-пространство не нужно делать большим, поскольку после инициализации экземпляра вы можете перенести физический и логические журналы в другое db-пространство. Возможность выполнять сортировку и упорядочение данных в памяти с помощью параметра NON_PDQ_QUERY_MEM и использование «временных» db-пространств еще более снижает необходимость в большом корневом db-пространстве.

Убедитесь, что в логических журналах достаточно места для создания системных БД во время инициализации экземпляра. После инициализации и конфигурирования экземпляра выполните архивирование логических журналов. После запуска экземпляра перенесите физический и логические журналы из корневого db-пространства.

Эта часть посвящена одному из очень редких аспектов администрирования IDS. в жизни гораздо чаще приходится сталкиваться с задачами изменения режима журналирования БД, администрированием db-пространств и BLOB-пространств, отстрелом пользовательских сессий. Следующая часть посвящена именно этим вопросам.

Часть 5. Основные административные задачи

В этой части: Изменение режимов работы экземпляра Изменение режимов журналирования БД Создание и удаление чанков, db-пространств, BLOB-пространств Перемещение журналов и изменение их размеров Безопасный отстрел пользовательского потока Автоматический запуск и останов экземпляра.

Если вы используете эту книгу в качестве пошагового учебника, то к этому моменту времени у вас уже должен быть установленный и инициализированный экземпляр Informix Dynamic Server. В этой части я сначала опишу графические инструменты администрирования, настройки и диагностики IDS. Я затрону базовые задачи администрирования сервера. Некоторые из них выполняются один раз для всего экземпляра, другие – более-менее регулярно. В большинстве случаев вы будете выполнять эти операции в командной строке или через интерфейс SQL API. После прочтения раздела вы сможете добавлять и удалять db-пространства, изменять режимы журналирования базы, перемещать журналы и изменять их размеры, корректно убивать пользовательские потоки. Утилиты администрирования Informix IDS поставляется с двумя графическими утилитами администрирования и одной текстовой. Я небольшой поклонник графических интерфейсов, поскольку все задачи администрирования IDS можно выполнять из командной строки. Однако, я понимаю, что многие пришедшие в администрирование IDS видели только графические интерфейсы. IDS OpenAdmin Tool (OAT) Этот инструмент разрабатывается в IBM Informix Advanced Technical Support. Изначально при разработке ставились такие задачи: обеспечить администратора необходимой для анализа информацией, дать ему возможность управлять SQL-запросами экземпляра, обеспечить интерфейс к новым возможностям мониторинга. OAT написан на PHP, исходный код открыт по лицензии Open Source, ОАТ предназначен для замены Informix Server Administrator (ISA). АPI SQL-администрирования Этот функционал появился в IDS 11 и позволяет выполнять администрирование экземпляра, используя вызовы функций SQL. Такая возможность была добавлена по нескольким причинам. Во-первых, стандартизация : это административное средство работает одинаково для IDS под разные ОС. Такая возможность особенно важна, если одновременно эксплуатируются сервера IDS под управлением разных ОС. Вторая причина – облегчение труда начинающих администраторов, многие из которых чувствуют себя неуютно при работе с сервером, который управляется в основном из командной строки. Одновременно такие администраторы вполне уверенно пишут SQL-запросы. Теперь администраторы могут выполнять многие административные задачи с помощью SQL, а не загадочных функций onmode, onparams. Кроме того, все больше и больше внимания уделяется безопасности серверов, содержащих БД с критическими данными. В таких системах отключен telnet и другие системы удаленного администрирования. Без возможности подключиться к удаленному серверу невозможно выполнять администрирование экземпляра IDS. При наличии SQL API нет необходимости в telnet-подключении – вы можете администрировать экземпляры через клиентское SQL-приложение. API администрирования является частью БД sysadmin и состоит из трех основных компонентов – двух определенных пользователем функций и таблицы истории, где фиксируются все действия, выполненные через API. Эти две функции, task() и admin(), идентичны по функциональности и могут использоваться взаимозаменяемо. Отличаются они возвращаемыми значениями после выполнения команды. Функция task() возвращает текстовую строку с описанием того, что сделала функция. Функция admin() возвращает целочисленное значение. Рассмотрим, например, выполнение одной и той же операции с помощью обоих функций:

execute function task (‘create dbspace’,’data_space_1’, ‘opt/IBM/informix/devices/amazon/ama_chnk_20’, ‘150mb’,’0’); (expression) created dbspace number 12 named data_space_1 или execute function admin(‘create dbspace’,’data_space_1’, ‘opt/IBM/informix/devices/amazon/ama_chnk_20’, ‘150mb’,’0’); (expression) 107 Возвращаемое целочисленное значение следующее значение: если число положительно, то оно представляет собой номер строки в таблице истории операций, выполненных через API, если число отрицательное, то это говорит о произошедшей ошибке, если значение равно 0 (ноль), то команда успешно выполнена, но в таблице истории нет места для вставки новой строки. По умолчанию БД sysadmin и ее объекты создается в корневом db-пространстве. Если вы выполняете множество операций через API, размер таблицы истории будет расти, и корневое db-пространство может переполнится. Существует два пути управления ростом таблицы истории. Во-первых, вы можете с помощью API перенести базу данных в другое db-пространство: execute function task (“reset sysadmin”,”целевое db-пространство”) После переноса БД sysadmin в это db-пространство, оно становится критическим с точки зрения функционирования экземпляра. Если db-пространство повредится, экземпляр прекратит функционирование. Второй метод подразумевает мониторинг и очистку таблицы. Таблица истории невелика. В Таблице 5.1 приведена ее схема

Схема таблицы command_history в базе данных sysadmin

Столбец Тип описание

cmd_number serial Уникальный идентификатор строки

cmd_exec_time datetime year-to-second Время, когда была выполнена команда

cmd_user varchar(254) Идентификатор пользователя, выполнявшего команду

cmd_hostname varchar(254) Компьютер, с которого была запущена команда

cmd_executed varchar(254) Текст выполненной команды

cmd_ret_status integer Код возврата команды

cmd_ret_message

lvarchar(30000)

Строка, возвращенная командой

База sysadmin предоставляет больше возможностей, чем просто выполнение функций администрирования экземпляра. В других частях книги мы обсудим использование этой БД для планирования выполнения операций, настройки производительности. Более подробно эти темы будут рассматриваться во второй книге. Изменение режимов работы Экземпляр Informix Dynamic Server может работать в различных операционных режимах с предоставлением различного уровня функциональности для конечных пользователей. В некоторых режимах экземпляр может работать продолжительное время, другие режимы являются переходными, но каждый из них имеет свое назначение. Раньше требовалось, чтобы для выполнения определенных функций администрирования экземпляр был переведен в определенный режим, на данный момент это неактуально. В IDS 11 вы можете выполнять практически все задачи администрирования без необходимости прерывания пользовательских потоков. Однако, администратору сервера необходимо понимать режимы работы сервера, как изменять эти режимы и т.п. Определить режим работы экземпляра можно несколькими методами. Самый трудоемкий способ – исследовать файл MSGPATH на предмет записей об изменении режима работы. Самый простой способ – выполнить команду onstat -. Эта команда выводит время работы сервера и режим его работы. В первой строке вывода команды всегда указывается режим работы сервера. Только пользователь root или Informix должны менять режим работы экземпляра. Обратите внимание, что члены группы DBSA (обычно члены групп informix, informixadmin на уровне ОС) могут менять режим работы любого экземпляра, используя команды oninit, onmode или SQL API. Желательно, чтобы учетная запись root не использовалась для изменения режима работы сервера, поскольку в этом случае процессы, поддерживающие ВП, которые выполняют UDR, получают права root. Если эти UDR выполняют внешние системные вызовы, то эти вывозы будут выполнены с правами root, что при наличии ошибок в UDR нежелательно.

В таблице 5.2 описаны 7 режимов работы экземпляра.

Таблица 5.2. Режимы работы экземпляра

Режим Описание

Административный (administrative)

Усовершенствование однопользовательского режима (single user) IDS 10. В этом режиме экземпляр находится в он-лайн, но к нему могут подключиться только пользователи, идентификаторы которых (ID) указаны через onmode –j –U, oninit –U или через конфигурационный параметр ADMIN_MODE_USERS. Список таких пользователей можно обновлять в любой момент, изменения применяются немедленно. Этот режим следует использовать только в особых случаях, когда необходимо ограничить доступ пользователей в систему на время выполнения некоторых административных задач

Офф-лайн (Offline) Экземпляр не запущен. Разделяемая память не выделена или не инициализирована. Виртуальные процессоры не запущены

Статический (quiescent) Экземпляр полностью функционален, но доступ к пользовательским БД невозможен. Этот режим очень похож на режим обслуживания в многопользовательских ОС. В этом режиме все пользователи, в том числе и informix, могут подключиться только к базам, доступным через SMI. В ранних версиях IDS некоторые административные задачи: удаление или добавление логических журналов, операции с физическим журналом, требовали перевода экземпляра в статический режим для своего завершения. В текущих версиях IDS алгоритм выполнения таких операций полностью переписан, поэтому сейчас нет необходимости изменять режим работы экземпляра.

Только чтение (read only)

В версиях до IDS 11.50 этот режим применим только к вторичным серверам в HDR или MACH-11. В этом режиме приложение имеет доступ к таблицам на вторичном сервере, но команды insert, update, delete запрещены

Восстановление (recovery)

Это промежуточный режим, используемый сервером во время инициализации разделяемой памяти и запуска виртуальных процессоров. В этом режиме выполняется быстрое восстановление. Если в этом режиме инициализирована разделяемая память, то SMI все равно недоступен

Выключение (shutdown) Еще один промежуточный режим. Он используется тогда, когда экземпляр переходит из он-лайн в статический режим или в офф-лайн. Если не было указано немедленное выключение, то пользовательские потоки могут завершить свою работу, но новые подключения к экземпляру и базе не

допускаются

Обновляемый (updatable)

В IDS 11.5 в этом режиме могут работать экземпляры, сконфигурированные как HDR, SDS (shared disk secondary), и/или RSS(remote standalone secondary). При включении этого режима становятся возможными DML операции и full end-user query. Параметр файла $ONCONFIG UPDATABLE_SECONDARY определяет, поддерживает ли вторичный сервер DML-операции. DDL-операции на данный момент не поддерживаются

Команда изменения режима работы экземпляра не может быть отменена. В зависимости от того, как вы изменяете режим работы и если есть пользовательские сессии, вы получите запрос на переход в другой режим. Если на этот запрос ответите отрицательно, экземпляр останется в исходном режиме работы, а команда будет отменена. С помощью двух команд вы можете остановить, перезапустить, переинициализировать экземпляр. Вы можете использовать и SQL API, но только не для старта или инициализации экземпляра, поскольку в эти моменты БД sysadmin недоступна. В IDS 11.50 ОАТ обеспечивает функциональность запуска экземпляра, находящегося в офф-лайн, эта функциональность требует конфигурации сервиса xinetd для взаимодействия с экземпляром. Утилита oninit может быть использована для перевода экземпляра из режима офф-лайн в один из следующих:

oninit –s (строчная буква s). Переводит сконфигурированный экземпляр из офф-лайн в статический режим.

oninit –S (прописная буква S). Переводит сконфигурированный экземпляр из офф-лайн в статический режим, но в этом случае если экземпляр раньше был частью HDR (первичным или вторичным сервером), то он будет работать как отдельный сервер и больше не будет частью пары HDR.

oninit –j. Переводит экземпляр из офф-лайн в административный режим. Обратите внимание, что в этом случае флаг –U для указания пользователей, которым разрешено подключение к экземпляру, не поддерживается. В результате к экземпляру могут подключиться только пользователь informix, члены группы DBSA и пользователи, указанные в конфигурационном параметре ADMIN_MODE_USERS.

oninit Без флагов переводит сконфигурированный экземпляр из офф-лайн в он-лайн

Утилита oninit поддерживает также флаг –р, который я не рекомендую использовать. При установке этого флага экземпляр во время своего запуска не будет удалять временные таблицы в корневом db-пространстве и остальных db-пространствах. Использование этой опции позволяет немного уменьшить время перехода из офф-лайн в он-лайн. С другой стороны, дисковое пространство, занятое временными таблицами, не будет очищено, пользовательские сессии к этим таблицам доступа иметь не будут, следовательно использование этого флага приводит к замусориванию дискового пространства. Я не думаю, что 10 секунд ожидания – это большая плата за очистку диска от ненужных

данных. У команды oninit, есть еще один флаг, с которым нужно быть очень осторожным – это флаг –i. Этот флаг инициализирует корневое db-пространство экземпляра, полностью стирая все данные, которые там находились. Используйте этот флаг только в том случае, если вы перенастраиваете экземпляр с самого начала. Для изменения режимов работы экземпляра используется команда onmode.

onmode –m Переводит экземпляр из статического режима в режимон-лайн onmode –s[y] Переводит экземпляр из режима он-лайн через режим выключения в

статический режим. Флаг –y отключает выдачу предупреждения. Эта команда запрещает новые подключения, но ждет завершения всех подключенных пользовательских сессий. Ждать этого она может бесконечное время. Для ускорения процесса выключения или если вам необходимо отстрелить пользовательское соединение используйте команду onmode –z session_id

onmode –k[y]. Корректно переводит экземпляр в режим офф-лайн – проводится обработка контрольной точки, транзакции откатываются

onmode –u[y]. Жестко прекращает работу экземпляра. В логических журналах транзакции помечаются для отката. Флаг –y отключает выдачу двух подтверждений.

Команда onmode также поддерживает флаги –z (отстрел пользовательских сессий), -а (увеличение сегмента разделяемой памяти), -с (инициализация обработки контрольной точки). Мы рассмотрим эти флаги подробнее в соответствующих разделах Изменение режима журналирования базы Как вы узнаете в Части 6, при создании БД необходимо выбрать режим журналирования. Режим журналирования определяет механизм записи измениний в БД. Если база данных находится в журналируемом режиме, сервер отслеживает ее изменения с помощью логического и физического журнала. Во второй книге я расскажу, как логический журнал используется для поддержания логической целостности данных. В предыдущих версиях IDS изменение режима журналирования нужно было делать время от времени, особенно во время обслуживания (changes to the logging mode of a database occurred with some regularity, particularly during maintenance periods). Такое, например, необходимо было делать для изменения структуры больших таблиц, чтобы не налететь на длинную транзакцию. В последних релизах IDS можно в «сырой» (нежурналируемый) режим перевести отдельную таблицу, не трогая остальных таблиц в БД. Эта возможность позволяет выполнять операции обслуживания таблиц без генерации записей в логическом журнале, одновременно журналируя операции пользователей. Есть ситуации, когда изменение режима журналирования необходимо. Например, вы собираетесь создать БД с помощью утилиты dbimport. В этом случае лучше создать базу данных с нежурналируемым режимом. Причина этого состоит в том, что сервер обрабатывает операцию импорта утилитой dbimport как одну транзакцию, и возможно возникновение долгой транзакции. После завершения импорта вы можете изменить режим журналирования базы. Второй причиной изменения режима журналирования может быть необходимость вненсения структурных изменений в большое количество таблиц во время обслуживания БД. В Части 6 приведено описание всех режимов журналирования БД, поддерживаемых Informix Dynamic Server. Давайте сейчас обсудим два типа журналирования: журналируемый и нежурналируемый. В процессе разработки IDS механизмы изменения режима журналирования неоднократно менялись. В ранних версиях IDS изменение режима журналирования можно было сделать только тогда, когда сервер находился в статическом режиме, некоторые изменения можно было проводить с помощью утилиты ontape. Затем стало возможно использовать для этой цели утилиты ON-Bar. Затем IBM выпустила утилиту ondblog, которая помечала БД для изменения

режима журналирования. Режим журналирования изменялся только после полного архива экземпляра. Отдельный пользователь мог изменить режим журналирования для своей сессии. Используя SQL-команду set log пользовательское приложение могло изменить режим журналирования своей сессии с небуферизированного журналирования на буферизированное и наоборот. Утилита ondblog устанавливает флаг изменения режима журналирования базы после выполнения архива 0-го уровня экземпляра через утилиту ontape или ON-Bar. Ниже приведен список флагов утилиты ondblog:

ansi. Режим журналирования ANSI cancel Отменяет изменение режима журналирования buf Буферизированное журналирование nolog Отключает журналирование unbuf Небуферизированное журналирование

После этих опций могут указываться один или два дополнительных параметра. Первый – список БД через пробел, для которых изменяется режим журналирования, второй – после флага –f указывается путь к файлу со списком баз, для которых должен быть изменен режим журналирования. Базы данных в файле записываются по одной в строке, без знаков препинания. При отсутствии дополнительных параметров утилита ondblog изменяет режим журналирования всех баз данных после выполнения архива 0-го уровня. Отключение журналирования или переход из нежурналируемого режима в журналируемый требует выполнения архива 0-го уровня с использованием ontape с или без использования ondblog или через ON-Bar с использованием ondblog. Используя ON-Bar или SQL API, вы можете создать «ложный» (fake) архив. Как я расскажу в Части 7 создание такого архива просто меняет некоторые флаги в экземпляре так, словно архивирование экземпляра было выполнено. Используйте эту возможность очень осторожно. Я рекомендую создавать правильный архив, и избегать использования этих опций. Изменить режим журналирования с помощью утилиты ontape довольно просто. ontape -U dbname – небуферизированное журналирование ontape –B dbname – буферизированное журналирование ontape –A dbname – ANSI-журналирование Чтобы изменить режим журналирования с журналируемого/нежурналируемого на другой, просто добавьте вышеуказанные флаги или флаг –N dbname (для перехода к небуферизированному журналированию) к команде ontape –s -L 0 (ноль). Для изменения режима журналирования нескольких баз используйте утилиту ondblog. При изменении режима журналированияэкземпляр может не находиться в статическом режиме, но к нему не должно быть активных пользовательских подключений, иначе вы получите загадочную ошибку –107 ISAM. Если вы прервете выполнение команды изменения режима журналирования базы, то база данных будет недоступна для пользователей до выполнения полного архива экземпляра. В ситуациях, когда необходимо изменить режим журналирования БД для проведения административных работ, есть возможность ускорить процесс создания архива и изменения режима журналирования. Первый способ – использовать утилиту ondblog для указания баз данных и режимов журналирования, а затем onbar –b –F для создания псевдо-архива. Это все, что необходимо утилите ondblog для изменения режима журналирования баз(ы) данных. Вторая возможность – отредактировать файл $ONCONFIG, временно указав в качестве архивного устройства (TAPEDEV) /dev/null, а затем выполнить команду ontape с или без

утилиты ondblog. Будет выполнено псевдо-архивирование, установлены необходимые флаги и изменен режим журналирования БД. Третий подход – использовать SQL API и использовать параметр archive fake в функциях task() или admin(). Естественно, перед изменением режима журналирования для проведения обслуживания БД, необходимо выполнить полное архивирование экземпляра на случай, если потребуется восстановление. После проведения обслуживания вы можете изменить режим журналирования назад одним из вышеописанных трех способов. После изменения режима обязательно выполните полное архивирование экземпляра. Управление db-пространствами и BLOB-пространствами Управлять db-пространствами и BLOB-пространствами можно через графические утилиты администрирования, команду onspaces и интерфейс SQL API. При создании db-пространств необходимо учитывать, как они будут размещены на физических дисках, какие таблицы будут находится в этих пространствах, и какой возможен рост размеров таблиц. В OLTP-приложениях быстроизменяющиеся таблицы следует распределять (и возможно фрагментировать) по небольшим высокопроизводительным дискам. Другие таблицы можно разложить по db-пространствам на более медленных дисках. В OLAP-системах требуются диски большой емкости, здесь при раскладывании таблиц по дискам более важна их логическая группировка. С удешевлением жестких дисков и развитием технологии массивов хранения стало сложнее максимизировать дисковый ввод/вывод базы. Почти невозможно найти небольшие по емкости жесткие диски, чтобы положить туда только меняющиеся таблицы. Администраторы массивов чаще всего идут по пути минимального сопротивления собирая все или почти все имеющиеся жесткие диски в RAID 1+0 (если вам повезло) или RAID 5 (если вам очень не повезло). Такие массивы легко администрировать, но на них тяжело достичь максимальной производительности IDS. Давайте рассмотрим некоторые общие вопросы. Для максимально производительной обработки контрольной точки желательно размещать чанки db-пространств по алгоритму round-robin на всех доступных жестких дисках. Хотя это правило было особенно актуально для IDS младше 11-й версии, оно и сейчас неплохо работает, минимизируя время обработки контрольной точки. Чистильщики страниц (CLEANERS), управляющие записью данных на диск при обработке контрольной точки, выделяются в порядке создания чанков (are allocated in chunk-creation order). Если вы создадите множество чанков на одном диске, то при обработке контрольной точки множество чистильщиков страниц будет писать на один и тот же диск. Распределение чанков по разным дискам позволяет добиться распараллеливания операций записи при обработке контрольной точки. Второе замечание касается различия в утилитах администрирования. Ниже я покажу, как использовать утилиту onspaces, графические программы администрирования и SQL API для выполнения одних и тех же операций. Важное различие в поведении этих утилит наблюдается при создании чанков для нового db-пространства или расширения уже существующего. При создании чанка и указании его размера утилита onspaces выделяет точно запрошенный вами объем дискового пространства в Кбайтах при указании флага –s. Тоже может быть справедливо для SQL API , если вы указываете размер в килобайтах: execute function task (‘create dbspace’, ’demo_space’, ‘/opt/IBM/informix/devices/test/test_space’, ‘50000KB’,’0’);

Если для создания чанков и db-пространств используется SQL API, то размер создаваемых объектов можно указывать в мегабайтах, гигабайтах и терабайтах. Например, execute function task (‘create dbspace’, ’demo_space_2’, ‘/opt/IBM/informix/devices/test/test_space_2’, ‘50МB’,’0’); При использовании ОАТ размер можно указывать только в мегабайтах или группах по 1024 КБайта. Каким бы методом вы не создавали объекты, вызов onstat –d показывает размер db-пространства в страницах размера PAGESIZE. В дальнейшем я буду называть db-пространства и BLOB-пространства общим термином db-пространство, хотя существуют различия в методах работы со smart BLOB-пространствами и простыми BLOB-пространствами. Типы логических устройств хранения. Вероятно, самое большое изменение в последних версиях IDS – это интеграция объектно-ориентированных возможностей в ядро DSA. Эта разработка предоставила разработкам баз данных и приложений новые возможности, которые отсутствуют в стандартных реляционных серверах. Некоторые новые типы данных требуют специальных пространств хранения, поэтому давайте еще раз посмотрим на физическую и логическую архитектуру хранения данных, которая представлена на рисунке 5.13

Рисунок 5.13. Физические (сплошные линии) и логические(пунктирные линии) структуры хранения данных

Базовая физическая единица хранения – страница данных (data page), которая имеет фиксированный размер, называемый размером страницы (page size), это минимальный объем данных чтения/записи диска. В зависимости от версии ОС размер страницы составляет 2 или 4 Кбайт. Физическими единицами хранения являются BLOB-страница (blobpage) и страница для хранения smart BLOB’ов (sbpage) . Sbpage похожа на страницу данных: она также имеет размер 2-4 Кбайт. BLOB-страницы могут иметь разные размеры. При установке размера BLOB-страниц необходимо принимать во внимание ограничения производительности и особенности хранения BLOB. Например, на BLOB-странице может хранится только один BLOB-объект, большинство ваших объектов имеют размер 6 Кбайт, поэтому если вы определите размер страницы в 10 Кбайт, то потеряете зря много дискового пространства. Каждое BLOB-пространство может иметь свой собственный размер страницы. Наборы страниц (простых или BLOB) называются чанками и являются минимальными администрируемыми единицами. Вы можете создать чанки на любом диске, физически подключенном к серверу, на котором выполняется экземпляр IDS. если чанк создается на сыром устройстве, страницы в чанке будут непрерывными, одна будет следовать за другой. Именно поэтому чанки на сырых устройствах более производительны. При создании чанков на ФС их страницы собраны логически с помощью механизмов файловой системы, а физически могут находится где угодно на файловой системе. Под громким выражением «администрирование чанка» подразумевается возможность удалить его из db/BLOB-пространства или добавить к db/BLOB-пространству. Максимальный размер чанка составляет 4 Тбайт или максимальный размер файла или сырого пространства, которым может управлять ваша ОС. На данный момент Informix может управлять БД размером 8 Петабайт. DB-пространство – это логическая единица хранения данных, состоит из одного или нескольких чанков. Поскольку чанки могут находится на разных дисках, db-пространство также может быть распределено среди нескольких дисков. Именно на этом уровне вы будете выполнять большинство административных задач: создавать базы данных, таблицы, индексы. Вы будете выполнять архивирование и восстановление db-пространств (мы пока не говорим о восстановлении таблиц с помощью archecker). Каждый экземпляр имеет хотя бы одно db-пространство – корневое, но большинство имеет больше. DB-пространства бывают нескольких типов. Администраторы чаще всего сталкиваются с обычными db-пространствами и временными пространствами. Стандартные db-пространства часто называют просто db-пространствами, они используются для хранения баз данных, таблиц, индексов, физического журнала и логических журналов. В зависимости от режима журналирования БД или отдельной таблицы, операции в этих пространствах могут журналироваться либо нет. Вы можете журналировать большинство db-пространств, что поможет усилить защиту сервера от физического сбоя. Временные db-ghjcnhfycndf (DBSPACETEMP) похожи на обычные пространства тем, что могут содержать таблицы и индексы, однако эти объекты не могут существовать в базе постоянно. Чуть позже мы рассмотрим временные db-пространства подробнее. Также широко используются BLOB-пространства и пространства subspace. Они применяются для хранения больших двоичных объектов (BLOB). BLOB-пространства могут хранить данные типа text и byte или простые типы данных BLOB, поэтому они часто называются простымиBLOB-пространствами (simple blobspaces). Sbspaces используются для хранения данных типа clob и blob( или типов данных smart blob), поэтому они называются smart blobspaces.

Архитектура sbspace отличается от архитектуры BLOB-пространства. Sbspaces имеют две области хранения – «пользовательскую», где непосредственно размещены данные и область метаданных, которые используются сервером БД для управления объектами этого пространства. Такая архитектура позволяет использовать байтовую блокировку объектов clob и blob, что позволяет нескольким пользователям работать с одним объектом одновременно. Пространство метаданных недоступно для пользователей, и его объем должен учитываться при расчете размера sbspace. Позже мы рассмотрим, как указать размер метаданных и дополнительные места хранения метаданных в sbspace. Эта возможность очень важна, так как в пространстве может закончиться область для хранения метаданных, но будет еще много места для хранения пользовательских данных. Каждый экземпляр имеет по крайней мере одно пространство sbspace (SYSSBSPACENAME) для хранения некоторой статистической информации. Если вы не планируете использовать smart BLOB’ы, то это пространство может быть небольшого размера – около 20 Мбайт. Однако некоторая функциональность экземпляра предполагает наличие одного или нескольких сконфигурированных sbspaces – например Enterprise Replication. Вы можете создать временные sbspaces (SBSPACETEMP). Они используются для хранения временных данных типа clob и blob. Преимущество временных пространств sbspaces – отсутствие области метаданных , операции с этими пространствами не журналируются. Внешние db-пространства (extspaces) – это расширение концепции db-пространств.DB-пространства целиком и полностью управляются IDS , а внешние db-пространства находятся не под управлением экземпляра, а просто регистрируются в нем. Внешние пространства могут хранить данные или индексы, но обычно эта информация сгенерирована не сервером Informix, а неким сторонним приложением, поэтому программист должен написать метод доступа к этим данным. Для выполнения этой работы сервер Informix предоставляет интерфейс виртуальных таблиц (Virtual Table Interface - VTI) и виртуальных индексов (Virtual Index Interface - VII). В большинстве случаев внешние пространства используются различными DataBlade-ами для получения доступа к данным, сформированным внешними приложениями. Иногда требования к хранению объекта не могут быть удовлетворены функционалом db-пространств IDS. хорошим примером может быть DataBlade текстового поиска (Basic Text Search (BTS) DataBlade). Индексы BTS должны храниться в плоском файле, поэтому они создаются во внешнем пространстве и управляются через интерфейс VII. Теперь давайте рассмотрим процесс создания чанков иdb-пространств. Если вы используете сырые устройства, то у вас есть два метода работы с чанками и db-пространствами. Первый - создавать чанк или db-пространство как подмножество большого дискового раздела. В этом случае вы используете средства ОС для создания большого по размеру раздела на диске. Второй подход – создавать отдельный раздел для каждого чанка и db-пространства. Чуть ниже мы рассмотрим эти альтернативы. Если вы используете выделенное пространство, эти проблемы не должны вас беспокоить, поскольку для каждого db-пространства или чанка вы создаете отдельный файл. Хотя в этом случае не используются смещения на диске, но в утилите onspaces их значения необходимо все равно задавать равными 0 (ноль) . Временные пространства. Как я уже говорил, существует два типа db-пространств – обычные и временные. Обычные db-пространства содержат в себе таблицы баз данных и индексы. Эти пространства могут зеркалироваться, журналироваться (если БД находится в журналируемом режиме), архивироваться утилитами ontape или ON-Bar.

IDS использует временные db-пространства для создания временных таблиц при выполнении хэш-джойнов (hash joins), сортировки по индексу, операций упорядочения. Пользовательские приложения также могут использовать временные db-пространства для создания явных и неявных временных объектов. Эти таблицы и/или индексы существуют только во время выполнения SQL-запроса, а затем уничтожаются. Временные db-пространства определяются через параметр DBSPACETEMP файла $ONCONFIG. Они не зеркалируются не архивируются и инициализируются при каждом перезапуске сервера. Действия с временными db-пространствами не журналируются сервером, это поведение не зависит от режима журналирования базы. Если вы создадите временные db-пространства, это не значит, что Informix будет создавать временные объекты в этих пространствах. По умолчанию IDS не использует временное пространство. При создании временного объекта необходимо явно указать, что он создается во временном db-пространстве, в противном случае он может быть создан в любом db-пространстве, в том числе и в корневом. Для создания нежурналируемой временной таблицы необходимо в выражение create temp table добавить квалификатор with no log create temp table ex_ample (div_no integer, area_no smallint, tot_sales decimal(12,2) ) with no log В IDS 11 введен новый конфигурационный параметр TEMPTABLE_NOLOG, который предписывает создавать все временные объекты во временных db-пространствах, даже если при создании такого объекта не указан соответствующий SQL-квалификатор. Этот параметр особенно полезен при наличии разработчиков, которые не особенно беспокоятся о корректном создании временных объектов. Если создано несколько временных db-пространств и при создании временного объекта не указывается , в каком. Временном пространстве его размещать, то для размещения будет использоваться алгоритм round-robin. Другой подход к максимизации использования временных db-пространств – использование переменной окружения $DBSPACETEMP для пользовательских сессий. Таким образом можно переопределить временные пространства, которые используются этими сессиями. Этот подход полезен в том случае, если одно приложение активно использует временное db-пространство, тогда все остальные приложения можно перенаправить на использование других db-пространств, что повысит производительность сервера. Смещения. Смещение – предопределенное расстояние от некоторой известной точки. Смещения используются для размещения нескольких чанков на одном сыром устройстве. На Рисунке 5.14 приведена иллюстрация

Рисунок 5.14 Сырые чанки на сыром разделе со смещениями На рисунке чанк db-пространства dbspace_1 создан в самом начале сырого устройства (смещение 0). Чанк имеет размер 200 «единиц» (в этом примере единицы измерения не имеют значения). Затем на устройстве создается еще один чанк. Чтобы этот чанк не переписал уже существующий, администратор во время его создания указывает через флаг offset утилиты onspaces или SQL API смещение этого чанка 220 единиц. Такой подход разделяет два чанка буфером размером 20 единиц. Вам необязательно создавать чанки именно в начале раздела, а затем спускаться к его концу. При создании чанка вы можете указать смещение на свой выбор. Я рекомендую в целях безопасности оставлять между двумя чанками свободное пространство размером несколько единиц.

Informix не проверяет корректность задания смещений и размеров чанков. Вы можете по ошибке создать один чанк в начале второго, что приведет к ошибкам целостности данных. Я настойчиво советую при создании нескольких чанков на сыром разделе аккуратно записывать начальное значение и размер чанка. В окружении, где процесс проектирования и реализации происходит «на лету», это позволит уменьшить количество проблем, связанных с разбиением диска и изменением размера db-пространств. При необходимости вы сможете добавить к db-пространству несколько чанков с разными смещениями. Другое преимущество использования смещений – улучшение контроля над месторасположением каждого чанка. С помощью смещения вы можете создавать чанк ближе к центру диска или дальше от него. С другой стороны, использование смещений усложняет мониторинг дисков. Для мониторинга активности чанков и db-пространств вы можете использовать утилиты IDS, но мониторинг средствами ОС становится практически бесполезным, поскольку эти утилиты работают на уровне разделов. Поскольку на одном жестком диске обычно находится один дисковый раздел, сложно отследить, какой чанк вносит самый большой вклад в операции ввода/вывода. Разделы Другой подход к работе с чанками и db-пространствами состоит в создании одного или нескольких разделов на диске и использовании каждого раздела для размещения одного чанка. Я предпочитаю именно этот подход, поскольку он упрощает мониторинг возможных проблемных мест средствами IDS и ОС. Конфигурирование размера страницы db-пространства. В IDS 9.4 была введена поддержка «больших чанков» и возможность создания очень больших пространств, а в IDS 10 -возможность создавать db-пространства с разным размером страницы (configurable page size - CPS). CPS предоставляет такие возможности:

индексные ключи большого размера. Необходимы для полной поддержки UNICODE

увеличение эффективности хранения и дискового ввода/вывода. Рассматривая первую возможность, важно помнить, что, в отличие от данных, которые могут находится на разных страницах, индексы должны полностью помещаться на одну страницу. Из-за незнания этого ограничения некоторые пользователи получили ошибки при создании или модификации индексов, когда размер индекса стал больше размера страницы. У вас могут возникнуть вопросы, как может не хватить 2 Кбайтного индекса, но такое вполне возможно, если у вас приложение с поддержкой двухбайтовых языков (UNICODE). Используя CPS, вы можете создавать индексы длиной до 3 Кбайт. Второе преимущество CPS – увеличение эффективности хранения и получения данных с диска – касается и страниц данных, и страниц индексов. Как уже говорилось, Informix обрабатывает данные постранично. Это значит, что для получения 3 Кбайт данных, размещенных на двух страницах, необходимо произвести две операции чтения. Если вы сократите количество чтений, то это увеличит производительность дискового ввода/вывода. Рассмотрим эффективность хранения. Перед началом я кратко расскажу о низкоуровневой работе IDS с диском. В зависимости от ОС, страница данных может быть размером 2 Кбайт или 4 КБайт. Не вся страница доступна для хранения данных или индексов. Для обычных db-пространств 28 байт каждой страницы резервируются для служебных целей. Некоторое дополнительное пространство занимается каждой строкой, но это мы пока не будем учитывать.

IDS всегда пытается хранить данные так, чтобы минимизировать дисковый ввод/вывод. Если на одной странице можно сохранить несколько строк, то Informix так и поступит. Если еще одна строка не помещается на страницу, то она будет записана на новую строку, поэтому для ее получения потребуется одна дополнительная операция чтения. Если длина строки превосходит размер страницы, например, длина строки составляет 3 Кбайт, а размер страницы равен 2 Кбайт, то основная часть строки будет размещаться на одной странице (называется домашняя страница или home page), а остаток страницы – на другой строке (остаточная страница или remainder page). Если возможно, то остаточная страница хранит данные нескольких строк. Основная идея – минимизация количества операций ввода/вывода. Используя CPS, вы можете управлять размером страниц db-пространств, где хранятся ваши данные. Вы можете увеличить плотность хранения и минимизировать дисковый ввод/вывод. Давайте рассмотрим пример. Предположим, размер строки таблицы равен 1200 байт. На IDS с размером страницы 2 Кбайт вы сможете использовать 2020 байт страницы (2048 байт –28 байт служебных данных). Первая вставленная строка размещается на странице 1. вторая вставленная строка не помещается на первой странице, поэтому она сохраняется на другой странице. В результате примерно половина объема страницы остается незанятой. Теперь предположим, что мы выбрали размер страниц равным 6 Кбайт, это даст 6116 байт используемого пространства на страницу. Результат значительно улучшится. Начиная с IDS 10, в утилите onspaces вы можете указать флаг –k для определения размера страницы db-пространства. Размер страницы должен быть кратен размеру страницы по умолчанию. Максимальный размер страницы 16 Кбайт. При использовании CPS необходимо помнить о некоторых ограничениях. Вне зависимости от размера страницы на ней может быть расположено максимум 255 строк. Поэтому не создавайте таблицу, содержащую 4-байтовую строку в db-пространстве с размером страницы 16 Кбайт. Системные db-пространства имеют размер страницы по умолчанию. Напомню, что это корневое db-пространство, db-пространства, где размещены физический и логический журнал, а также БД sysadmin. При создании одного или нескольких db-пространств с размером страницы не по умолчанию, для db-пространства с этим размером страницы создается буферный пул. Иллюстрацию смотрите на Рис 5.17

Рисунок 5.17. Отдельный буферный пул для db-пространств с разным размером страниц. Вопрос о создании пула памяти на основе параметров CPS относится только к стандартным db-пространствам, BLOB-пространства не рассматриваются. Если вы посмотрите в конец файла $ONCONFIG, то увидите новый синтаксис конфигурирования пулов буферов. Здесь располагается «значение по умолчанию», которое используется как шаблон утилитой onspaces, если новый пул должен быть создан в процессе создания пространства с размером страницы не по умолчанию. Вы можете

отредактировать это значение, если хотите, чтобы все последующие пулы использовали это значение. В файле также находится запись для размера страницы по умолчанию, которая используется корневым db-пространством. Давайте рассмотрим, как это работает на практике. Предположим, что вы разворачиваете экземпляр Informix и хотите создать первое db-пространство, используя CPS. Если вы создадите db-пространство с помощью команды onspaces, SQL API или какого-то графического инструмента, то команда создания db-пространства заодно создаст буферный пул с параметрами по умолчанию. Если эти параметры вам не подходят, то необходимо остановить экземпляр, изменить значения в файле $ONCONFIG для этого пула и перезапустить экземпляр. В качестве альтернативы вы можете создать сначала буферный пул с желаемыми параметрами. Созданное потом пространство будет использовать соответствующий пул такого же размера. Создать буфер можно с помощью утилиты onparams или SQL API: onparams –b –g page_size –n num_buffs – r num_lrus -x lru_max_dirty –m lru_min_dirty execute function admin (‘add bufferpool’, ‘pg_size’, ‘num_buffs’, ‘num_lrus’,’lru_max_dirty’, ’lru_min_dirty); Есть еще одно преимущество использования CPS. Предположим, что у вас высококонкуррентное окружение, где обрабатываются большие объемы данных из разных таблиц, и эти таблицы должны находится в памяти. Вы можете создать эти таблицы в db-пространствах с разным размером страницы. В результате данные разных таблиц будут кэшироваться в разных буферных пулах, тем самым повышая возможность экземпляра оперировать с этими данными в памяти и снижая уровень замусоривания пула и уменьшая необходимость чтения с диска данных, которые вытолкнуты из кэша. Такой подход улучшит производительность сервера. Соглашения о наименованиях в Informix под Windows Этот раздел касается только Informix под Microsoft Windows. Пользователям других ОС его можно пропустить. При развертывании Informix под Windows при именовании чанков необходимо придерживаться соглашения об именовании. Informix под Windows не использует символические ссылки при определении пути к устройствам экземпляра. Сервер предполагает наличие на дисках подкаталогов корневого db-пространства, начального db-пространства и их зеркальных копий (если используется зеркалирование) (The data server expects to see a needed set of subdirectories created on the drives supporting the rootdbs, the initial dbspace, and their mirror if IDS mirroring is used). Из-за наличия реестра Windows нет возможности указать, где создается корневое db-пространство экземпляра. Этот путь жестко закодирован в сервер. Структура каталогов также зашита в сервер. Если при инсталляции сервера вы выбрали создание демонстрационного экземпляра, чанки этого экземпляра будут созданы в соответствии с этим путем по умолчанию. Путь такой: %ROOTPATH%\IFMXDATA\instance_name, где instance_name – имя экземпляра. С помощью onspaces и графических утилит вы можете выбрать другой путь, но рекомендуется не изменять структуру каталогов. Имена файлов в каталоге состоят из трех частей (смотрите Таблицу 5.3)

Таблица 5.3. Соглашение об именовании файлов в Informix под Windows

Часть имени файла Описание

Имя пространства Имя db-пространства, которому принадлежит данный чанк. Максимальная длина этой части имени составляет 18 символов, в имени могут использоваться цифры и буквы, первый символ не должен быть числом или специальным символом.

Тип пространства Мнимое расширение, определяющее, к какому типу пространства относится этот файл. Возможные значения – dat для первичного чанка, mirr – для зеркального чанка.

Номер чанка Трехсимвольный номер для указания номера чанка/файла в именованном пространстве. Начальный чанк пространства нумеруется 000 (три нуля), последующие чанки имеют номера 001, 002 и т.д

В имени файла имя пространства и тип пространства разделяются с помощью символа нижнего подчеркивания ( _ ), а номер чанка записывается после точки. В результате в каталоге C:\IFMXDATA\sarthe, который содержит экземпляр sarthe на моем компьютере, будут находится такие файлы: rootdbs_dat.000 sarthe_1_dat.000 somebiglongnamefor_dat.000 sarthe_2_mirr.000 sarthe_3_dat.001 В этом примере у меня есть первичные чанки для db-пространств (rootdbs, sarthe_1, somebiglongnamefor), зеркальный чанк (sarthe_2) и дополнительный чанк, добавленный в db-пространство sarthe_3, начальный чанк этого db-пространства располагается на другом диске. Создание пространств. При создании экземпляра вы создаете начальное db-пространство, которое обычно называется rootdbs. Это db-пространство создается, если вы корректно установили такие параметры файла $ONCONFIG: ROOTNAME, ROOTSIZE, ROOTOFFSET, ROOTPATH, MIRRORPATH (если используется). После того, как экземпляр запущен и работает, необходимо добавить нужные db-пространства. Сделать это можно используя утилиту onspaces, OAT, Server Studio, SQL API. Создание db-пространства после инициализации экземпляра не сильно отличается от создания корневого db-пространства. Как говорилось в Части 2 в версиях IDS для Linux, Mac OS X, UNIX необходимо использовать не реальные имена устройств, а символические ссылки. Дальше в тексте я полагаю, что вы делаете именно так. Для создания db-пространства из командной строки используется утилита onspaces. Ниже приведены ее самые популярные флаги

-c - обозначает, что это создание объекта -d - имя db-пространства -p путь_к_устройству – путь к символической ссылке, указывающей на дисковый

раздел -o значение_смещения – смещение (если необходимо) на дисковом разделе. Если

смещение не нужно, указывается значение 0 (ноль) -s размер – размер db-пространства в килобайтах. -k размер_страницы – опционально. Определяет размер страницы db-

пространства в килобайтах. Кратное размеру страницы по умолчанию. Если не указано, то db-пространство создается с размером страницы по умолчанию.

-t - указывает на то, что создается временное db-пространство Если db-пространство зеркалируется, необходимо указать следующий флаг:

-m путь_к_устройству смещение – путь к символической ссылке, указывающей на зеркальный дисковый раздел и значение смещения (если необходимо). Если смещения нет, то указывается значение 0 (ноль).

Например, создадим 100 Мбайтное зеркалируемое db-пространство index_1 onspaces –c –d index_1 \ -p /opt/IBM/informix/devices/amazon/ama_chnk_1 –o 0 –s 100000 \ -m /opt/IBM/informix/devices/amazon/ama_chnk_12 0 Вышеприведенная команда должна быть записана в одну строку. Символ «\», обозначающий продолжение ввода, будет изредка встречаться и дальше в книге. Если вы не хотите зеркалировать db-пространство, то при вводе предыдущей команды опустите эту часть: -m /opt/IBM/informix/devices/amazon/ama_chnk_12 0. Для создания временного db-пространства work_space_1 размером 150 Мбайт и смещением 200 Мбайт выполните команду: onspaces –c –d work_space_1 \ -p /opt/IBM/informix/devices/amazon/ama_chnk_20 \ -s 150000 –o 200000 –t Создадим db-пространство archive_space размером 1 Гбайт с размером страницы 12 Кбайт: onspaces –c –d archive_space \ -p /opt/IBM/informix/devices/amazon/ama_chnk_2y \ -s 1000000 –o 0 –k 12 вы можете выполнять эти операции и с помощью SQL API IDS 11. Как вы видели ранее, можно использовать взаимозаменяемые функции task() и admin(). Они выполняют одинаковые действия, поэтому в примерах мы используем одну из них. При использовании SQL API обязательно проверяйте, что вы задали параметры команды в правильном порядке. Этот порядок определяется утилитой, функционал которой используется. Например, при создании db-пространства его размер должен быть указан перед значением смещения. В противном случае вы создадите db-пространство размером 0 Мбайт и смещением 200 Гбайт на сыром разделе.

Например, создадим временное db-пространство work_space_1 размером 150 Мбайт, со смещением 200 Мбайт execute function task (‘create tempdbspace’, ‘work_space_1’, ‘opt/IBM/informix/devices/amazon/ama_chnk_20’, ‘150mb’,’200mb’) По этой записи необходимо сделать несколько замечание. Синтаксис создания временного db-пространства отличается от синтаксиса создания обычного db-пространства. В Informix 11.5 введен дополнительный синтаксис создания db-пространств с помощью SQL API. Ключевое слово with_check используется для проверки существования физического устройства, путь к которому указывается при создании db-пространства. Для создания BLOB-пространств, простых или smart-, применяются свои флаги и единицы измерения. Поэтому переходим к этому вопросу. Простые BLOB-пространства Для создания простого BLOB-пространства необходимо из утилиты onspaces исключить флаг –d имя_db_пространства и использовать следующие дополнительные флаги

-b имя_blob – определяет имя BLOB-пространства -g размер_страницы – размер страницы BLOB-пространства в страницах, а не

килобайтах Например, создадим незеркалируемое BLOB-пространство размером 1 Гбайт, размер страницы пространства положим равным трем страницам. onspaces –c –b blob_world \ -p /opt/IBM/informix/devices/amazon/ama_chnk_3 \ -s 1000000 –o 0 –g 3 На SQL API это будет выглядеть так: execute function task (‘create with_check blobspace’, ‘blob_world’, ‘opt/IBM/informix/devices/amazon/ ama_chnk_3’, ‘1gb’,’0’,’3’); Нельзя создать «временные» простые BLOB-пространства. Но простые BLOB-пространства можно зеркалировать. Простые BLOB-пространства работают почти так же, как и обычные BLOB-пространства, но есть и некоторые отличия. В отличие от обычного db-пространства, которое доступно для использования сразу после создания (и для зеркалирования, если оно проводится на уровне экземпляра), то в случае BLOB-пространства записи о его создании и активации должны располагаться в двух отдельных логических журналах. Это означает, что необходимо будет переключить журналы с помощью команды onmode –l (строчная буква L), а потом нужно выполнить обработку контрольной точки командой onmode –c. Обычное db-пространство может быть создано с размером страницы, который является кратным размеру страницы по умолчанию. В случае BLOB-пространство, при его создании необходимо явно указать размер страницы. Минимальный размер страницы

равен 1 (единица). Один BLOB-объект может занимать несколько BLOB-страниц, но на BLOB-странице может быть только один BLOB-объект, поэтому выбирать размер BLOB-страницы следует внимательно, не надо делать ее слишком большой или слишком маленькой. Оптимально если размер BLOB-страницы максимально близок к среднему размеру BLOB-объекта. Я понимаю, что термин «средний размер» может ввести в заблуждение. Средний размер можно вычислить двумя способами. Первый – просуммировать размеры BLOB'ов и разделить на их количество. Но в этом случае плохо учитываются BLOB’ы больших размеров. It is more appropriate to look at the average BLOB to be stored in terms of volume and size and calculate the BLOBpage size form that. (не совсем ясно, в чем принципиальное отличие). Если размеры BLOB-объектов в таблицах сильно отличаются друг от друга, то целесообразно создать несколько BLOB-пространств с разным размером страницы. Эффективность хранения BLOB-страниц в BLOB-пространствах можно получить, вызвав команду onstat –pB. Smart BLOB-пространства Эти пространства имеют свой собственный набор флагов для создания и управления. При создании пространства указывается флаг –S . большинство флагов утилиты onspaces применимы к этим пространствам, включая флаги пути, смещения, размера, зеркалирования. Поскольку объекты в sb-пространстве могут иметь разные характеристики и разрешать одновременный доступ к ним нескольких пользователей, то для поддержки этого функционала были введены дополнительные флаги. Первые два флага –Ms значение_размера и –Mo значение_смещения управляют размером области метаданных в sb-пространстве и смещением, по которому создается область метаданных. Если не указать один из этих параметров, то IDS создаст область метаданных в середине sb-пространства. При вычислении размера области метаданных сервер на основе размера всего sb-пространства попробует «угадать», сколько smart BLOB-ов может храниться в таком объеме пространства. Если сервер ошибется, и вам будет не хватать места для хранения метаданных, вы сможете добавить к пространству чанк, в котором будут храниться только метаданные пространства (более подробно смотрите следующий раздел). Если вы знаете ожидаемый объем BLOB-ов, которые будут храниться в этом пространстве, то можете попробовать помочь серверу вычислить правильный размер области метаданных. Ниже мы обсудим необходимые параметры. Дополнительные параметры, позволяющие контролировать функциональность sb-пространства, указываются после флага –Df. Параметры указываются в строке, ограниченной двойными кавычками, каждый параметр отделяется от предыдущего запятой, пробелы между параметрами не допускаются. Строка является регистро-чуствительной, поэтому будьте аккуратны. В таблице 5.4 приведены часто используемые параметры. Если не сказано обратное, то размер указывается в килобайтах.

Таблица 5.4 Дополнительные параметры контроля функционирования sb-пространств

Флаг Описание

ACCESSTIME Отслеживает ли экземпляр время доступа к smart BLOB-у. Возможные значения OFF (по умолчанию) или ON

AVG_LO_SIZE Ожидаемый средний размер BLOB-а sb-пространства. Если флаг установлен, сервер будет использовать это значение при вычислении размера области метаданных. Если не используется, желательно установить значение параметра меньше, чем размер страницы по умолчанию. Максимальное значение 232 КБайт

BUFFERING Определяет, как буферизируются smart BLOB-ы. Если включено (ON по умолчанию), используется память из буферного пула резидентной памяти. Если OFF, используется память из виртуальной части разделяемой памяти экземпляра.

LOCK_MODE

Определяет режим блокировки объекта. Если установлено значение BLOB (по умолчанию), первый пользователь блокирует весь объект (как и в случае с простыми BLOB’ами). Если установлено RANGE, пользователь блокирует только ту часть объекта, с которой работает. Для поддержки блокировки RANGE должен быть установлен параметр BUFFERING ON.

LOGGING Определяет, журналируются ли изменения smart BLOB’ов. По умолчанию не журналируются (OFF).

MIN_EXT_SIZE Specifies the minimum amount of storage for each smart BLOB. Если не используется, лучше установить значение меньше, чем размер страницы по умолчанию. Максимальное значение параметра 322 КБайт

В следующем примере создается sb-пространство размером 500 Мбайт с такими параметрами, как режим блокировки= RANGE, журналирование изменений, буферизация объектов в резидентной памяти onspaces –c –S pics_sbspace \ -p /opt/IBM/informix/devices/tagus/sbspace_3 \ -s 500000 –o 0 \ -Df “AVG_LO_SIZE=2,LOGGING=ON, LOCK_MODE=RANGE,\ BUFFERING=ON” Параметр LOGGING определяет, проводится ли журналирование изменений BLOB-объектов. Изменения в области метаданных журналируются всегда. Добавление дискового чанка. Расширение пространства путем добавления чанка немного отличается от создания этого пространства. Если вы создали зеркалируемое средствами Informix пространство, то дополнительные чанки, добавляемые к тому пространству, также должны зеркалироваться. В этом случае вы должны добавить к пространству зеркалируемый чанк, а затем, при необходимости, можете отменить зеркалирование. Чтобы добавить чанк к пространству, используйте утилиту onspaces со следующими флагами:

-a db_пространство – имя пространства --p путь_к_устройству –полный путь символической ссылки, указывающей на

дисковый чанк -o значение_смещения – значение смещения. Если не нужно, указать 0 (ноль) -s размер_чанка – размер чанка в килобайтах.

Если используется зеркалирование чанка средствами Informix, укажите следующий флаг утилиты onspaces

-m путь смещение – полный путь символической ссылки, указывающей на зеркальный чанк и значение смещения в Кбайт. Если смещения нет, указать 0 (ноль)

при добавлении чанка в db-пространство под Windows не забывайте правильно указать номер чанка в имени файла (см Таблицу 5.3). Например, добавим чанк размером 1 Гбайт к BLOB-пространству my_blobs, используя SQL API execute function task (“add chunk”, “my_blobs”, “f:f_sarthe_disks/myblobs_dat.001”,”1000MB”,”0”); Обратите внимание, что при добавлении чанков не используется опция with_check. При добавлении чанка в sb-пространство, можно указать, будут ли в этом чанке храниться только метаданные, или будут и данные, и метаданные. Эта возможность особенно полезна, если ваши расчеты по размеру метаданных оказались ошибочными. Управлять добавлением чанка к sb-пространству можно с помощью двух дополнительных флагов утилиты onspaces.

-Ms размер – какой объем дискового пространства в чанке предназначен для хранения метаданных

-Mo значение_смещения – смещение(в килобайтах) области метаданных в чанке. Я не нашел документированного API добавления чанка в sb-пространство и управления размещением метаданных. Удаление чанка. В большинстве случаев удаление чанка возможно в том момент, когда пространство находится в он-лайн. Исключением являются простые BLOB-пространства. Удаление чанка из простого BLOB-пространства требует, чтобы экземпляр находился в статическом режиме. Перед удалением необходимо убедиться, что чанк пустой. Для этого из командной строки запустите oncheck –pe, направьте вывод в файл и проанализируйте этот файл. Каждый чанк db-пространства будет показан отдельно с указанием табличных или индексных экстентов, которые находятся в этом чанке. Если в чанке, который планируется удалить, находятся экстенты таблиц или индексов, то попробуйте удалить эти экстенты или перенести их в другой чанк. Вы можете выгрузить таблицы, удалить их и создать заново в другом db-пространстве. Изменение схемы распределения данных по db-пространствам вызывает перестройку затронутых этим процессом разделов. Смотрите в Части 6 тему «Изменение разделов». Если чанк пуст, то для его удаления можно вызвать утилиту onspaces со следующими флагами:

-d имя_пространства имя db-пространства, из которого удаляется чанк -p путь_к_устройству – полный путь к символической ссылке, указывающей на

удаляемый чанк -o значение_смещения – значение смещения в файле (в килобайтах). Если

смещения нет, то указать 0 (ноль) -y - утвердительный ответ на вопрос подтверждения действия.

Можно также использовать функции SQL API с этими параметрами. Если чанк не пустой, то процесс его удаления будет отменен и будет выведено сообщение об ошибке. Такой поведение может быть проблемой в том случае, когда область метаданных дополнительного чанка sb-пространства используется для хранения данных о пользовательских объектах, размещенных в других чанках. В этом случае вам не удастся удалить отдельный чанк – необходимо удалять все sb-пространство. Если в дополнительном чанке хранятся только пользовательские данные, то чанк может быть удален даже в том случае, когда он не пустой. Выполнение этой операции требует указания флага –f в утилите onspaces. Я настоятельно рекомендую после добавления/удаления чанка выполнять полное архивирование экземпляра. Начальный чанк db-пространства не может быть удален. Даже в том случае, когда в db-пространстве есть еще чанки. Для удаления начального чанка необходимо удалить все db-пространство. Удаление пространства. Вы не можете удалить пространство, если оно содержит табличные или индексные экстенты. Для проверки того, какие экстенты размещены в пространстве используйте утилиту oncheck –pe, как описано в предыдущем разделе. Sb-пространство можно удалить даже если в нем содержатся пользовательские данные. Для этого используйте в нижеописанной командной строке флаг –f Удаление db-пространства утилитой onspaces требует передачи ей двух параметров.

-d имя_пространства - имя удаляемого db-пространства -y – подтверждение удаления

SQL API требует только параметра drop dbspace и имени этого db-пространства. Если db-пространство не свободно, его удаление не произойдет, и будет выведено сообщение об ошибке. Удалять пространства можно и с помощью ОАТ. Если вы удалили пространство, созданное с использованием выделенных файлов, файлы не будут удалены автоматически – их нужно удалять руками. Добавление и удаление зеркалирования. Если при создании экземпляра зеркалирование средствами Informix не было включено, то вы можете включить его в любое время редактированием файла $ONCONFIG. Зеркалированием управляет конфигурационный параметр MIRROR. Если установлено MIRROR=1, то зеркалирование включено, иначе – отключено. К сожалению, изменение этого параметра требует перезапуска экземпляра. Для настройки зеркалирования db-пространства средствами Informix можно использовать утилиту onspaces или SQL API. Применяются такие флаги:

-m имя_пространства – определяет имя db-пространства -p путь_к_устройству – полный путь к символической ссылке, указывающей на

чанк, который необходимо зеркалировать

-o смещение_первичного_чанка – смещение (в килобайтах) зеркалируемого чанка. Если не используется – указать 0 (ноль)

-m путь_к_зеркалу смещение_зеркального_чанка – полный путь к символической ссылке, указывающей на зеркальный чанк и смещение в килобайтах. Если смещение не используется, указать 0 (ноль).

-y – подтверждение включения зеркалирования Например, выполним зеркалирование средствами Informixdb-пространства dbs_1: onspaces –m dbs_1 \ -p /opt/IBM/informix/devices/tagus/dbs_1 –o 0 \ -m /opt/IBM/informix/devices/tagus/dbs_1_mirror 0 –y Удаление зеркалирования – тоже простая операция. Можно отключить только зеркалирования всего пространства. Выключение зеркалирования подразумевает использование следующих флагов утилиты onspaces:

-r имя_пространства -имя пространства, зеркалирование которого удаляется -y -подтверждение удаления

Удалить зеркалирование можно средствами SQL API, используя параметр stop mirroring и имя db-пространства. Удаление зеркалирования не означает удаления файлов или дисковых разделов, на которых хранились зеркальные копии, а также символических ссылок на эти разделы и файлы – все эти объекты просто больше не используются экземпляром, а удалять их необходимо вручную. Изменение статуса чанка. Когда активно зеркалирование пространства средствами Informix и чанки сконфигурированы в зеркальные пары, вы можете отключить/включить один из чанков этой зеркальной пары, второй член этой пары будет полностью работоспособен. Одна из причин , по котором иногда такое приходится делать, - физические переместить диски, на которые указывают символические ссылки, без необходимости экспортировать, удалять и пересоздавать таблицы. Этот процесс включает в себя остановку зеркалирования, изменение дискового раздела, на который указывает символическая ссылка, а затем включение зеркалирования. При переводе отключенного чанка в он-лайн Informix делает на него побитовую копию данных чанка, который был активным в это время. Этот процесс не отличается от того, который происходит, когда зеркалирование включается. К сожалению, изменить статус чанка через ОАТ невозможно, поэтому необходимо использовать консольные утилиты или SQL API. При использовании утилиты onspaces флаг –D отключает чанк, а флаг –О (заглавная буква О) переводит чанк в он-лайн. Полный синтаксис изменения статуса чанка такой:

-s имя_пространства – определяет имя db-пространства -p путь_к_устройству – полный путь к символической ссылке, указывающей на

чанк, который переводится в оффлайн или он-лайн. -o значение_смещения – значение смещения в килобайтах. Если нет, указать 0

(ноль) -D или –О – определяет действие, совершаемое над чанком: D-отключить (down),

O-включить (online) -y – утвердительный ответ

Например, отключим первичный чанк db-пространства danube_1 onspaces –s danube_1 \ -p /opt/IBM/informix/devices/Danube/dan_1 –o 0 –D –y Когда чанк переводится в оффлайн, это событие журналируется в файле MSGPATH и в ОАТ регистрируется предупреждение. Статус чанка также можно увидеть с помощью команды onstat –d. Установка и изменение параметра DATASKIP Этот параметр определяет поведение экземпляра при обработке запросов, которые требуют получения данных из пространств, которые недоступны в результате дискового сбоя или по какой-то другой причине. Если значение параметра равно OFF, то запрос завершается ошибкой. Если значение параметра равно ON, неважно для всех db-пространств (ALL) или для некоторого их списка, и запросу необходимо получить данные из отключенных db-пространств, то запрос завершится получением тех данных, которые он может получить, но клиентскому приложению вернется сообщение об ошибке. Изменить значение параметра DATASKIP можно путем редактирования файла $ONCONFIG, с помощью утилиты onspaces или через SQL API. Приложение в своей сессии может переопределить значение параметра путем вызова SQL-команды set dataskip. Чтобы изменить значение параметра DATASKIP с помощью утилиты onspaces необходимо вызвать эту утилиту с флагом –f и передать в нее один или два параметра

-f OFF или ON [ALL | список_имен_пространств] -y - утвердительный ответ на запрос подтверждения

Использование только ключевого слова ON или OFF подразумевает, что оно повлияет на все пространства экземпляра, что делает ключевое слово ALL избыточным. Если необходимо установить параметр DATASKIP для определенных пространств, то их список через запятую необходимо указать после слов ON/OFF . Значение DATASKIP, установленное с помощью onspaces, действительно во время работы экземпляра. При перезапуске экземпляра восстанавливается значение этого параметра, указанное в файле $ONCONFIG. Чтобы необходимое значение DATASKIP сохранялось после перезапуска экземпляра, необходимо отредактировать файл $ONCONFIG, установив для этого параметра желаемое значение. В файле также поддерживается указание ключевых слов ALL и списка необходимых пространств. Создание, перемещение и изменение размеров журналов. Одна из первых задач, которые должны быть решены после инициализации экземпляра, который будет управлять журналируемыми базами данных, это создание одного или нескольких db-пространств для хранения физического журнала и логических журналов, вынесение журналов из корневого db-пространства и создание новых логических журналов. Вынесение журналов из корневого db-пространства уменьшает дисковый ввод/вывод по устройству. Если все БД экземпляра будут нежурналируемыми, то необходимости перенесения журналов в другое db-пространство нет, кроме, возможно, желания очистить место в корневом db-пространстве. Для нежурналируемых БД запись в журналы практически не производятся. Если экземпляр содержит журналируемые базы данных, вы должны побеспокоится о количестве и размере логических журналов. К счастью, сейчас управление журналами

упростилось. Вы можете сконфигурировать экземпляр на автоматическое добавление журналов при необходимости. Рекомендуется размещать физический журнал и логические журналы в отдельных db-пространствах. Дисковый ввод/вывод логических журналов может быть очень большим, поэтому желательно размещать чанки пространства, в котором находятся логические журналы, на быстрых устройствах. При желании вы можете разместить логические журналы в нескольких db-пространствах, но требования так делать нет. Важно помнить, что любое db-пространство, в котором находятся журналы, становится с точки зрения сервера БД, критическим. Не забудьте о зеркалировании этого пространства средствами Informix или RAID Физический журнал В IDS 11 администрирование физического журнала значительно улучшено. В предыдущих версиях IDS для перемещения или изменения размера физического журнала было необходимо, чтобы экземпляр находился в статическом режиме. В IDS 11 вы можете изменять размер и размещение журнала без прерывания операций экземпляра. однако необходимо выполнить некоторые условия. Во-первых, выполнять эти операции можно только через onparams, onmonitor и потенциально через ОАТ, Server Studio и SQL API. Раньше администраторы занимались «читерством» - переводили экземпляр в офф-лайн, модифицировали параметры физического журнала в файле $ONCONFIG, а затем перезапускали экземпляр. Если вы так поступите сейчас, то подвергнете экземпляр большой опасности: есть вероятность, что он вообще не запустится. Во-вторых , изменение физического журнала – это не in-place операция. Ниже мы увидим, что некоторые DDL-операции касаются только отдельных строк таблицы (in-place table alters), а другие DDL-операции касаются всей таблицы. Во втором случае исходная таблица существует до тех пор, пока не будет создана ее полная копия и эта копия не будет загружена с новыми определениями. Когда новая копия активируется, старая удаляется. В результате вам необходимо место для хранения и оригинала, и новой копии. Эти рассуждения касаются и администрирования физического журнала. Если вы изменяете режим журнала, но оставляете его в том же db-пространстве, то вам нужно иметь достаточно места для нового и старого журнала. В противном случае операция завершится ошибкой. Третье, после операций администрирования физического журнала необходимо создать полный архив экземпляра. Для изменения размера или месторасположения физического журнала используется утилита onparams со следующими флагами:

-p –s размер_в_килобайтах – определяет новый размер журнала в килобайтах или текущий размер журнала, если вы не меняете размер

-d имя_db_пространства – название db-пространства, в котором будет храниться физический журнал

-y – ответ на запрос подтверждения Размер физического журнала важен по нескольким причинам. Во-первых, при заполнении журнала на 75% экземпляр инициирует обработку контрольной точки (full checkpoint). Во-вторых, начиная с IDS 11 в физическом журнале хранится больше данных в течении большего промежутка времени. Благодаря новому неблокирующему алгоритму обработки контрольной точки теперь экземпляр во время контрольной точки не прерывает операции. Разработчики IDS рекомендуют устанавливать размер физического журнала равным 110 процентов размера буферов памяти экземпляра (110 percent of the instance memory buffer pool). При необходимости вы можете пересмотреть

эту рекомендацию, приняв во внимание особенности вашей системы, нагрузку на нее. Это та область, где справедливо выражение «если этого достаточно, то больше - лучше». Вы можете мониторить физический журнал и его буферы командами onstat –l (строчная буква l) и oncheck –pr. С помощью этих команд вы можете увидеть, какой процент журнала используется во время обработки контрольной точки. Подробную информацию о последних чекпоинтах можно получить с помощью команды onstat –g ckp. Логические журналы. Логические журналы администрировать проще, чем физический. В старых версиях IDS для добавления нового журнала было необходимо переводить экземпляр в статический режим, и новый журнал добавлялся в конец цепочки журналов. Эти ограничения были убраны в ранних выпусках IDS 9. сейчас вы можете администрировать логические журналы когда экземпляр находится он-лайн и обрабатывает запросы пользователей. Новые логические журналы могут быть вставлены в текущую позицию цепочки журналов или в ее конец. Логические журналы могут иметь разный размер. Вы можете сконфигурировать автоматическое добавление журналов, что очень полезно, если экземпляру не хватает логических журналов из-за больших транзакций или транзакции, которая не была своевременно закрыта и остается открытой в нескольких журналах. Эта возможность не отменяет отката длинной транзакции, но дает экземпляру больше места на эту операцию. Также, начиная с IDS 9, логический журнал можно использовать сразу после его добавления. Для активации логического журнала нет необходимости выполнять полное архивирование экземпляра. Неизменным остается одно – в экземпляре не может быть меньше трех логических журналов. Результатом этого является двухступенчатый процесс перемещения логических журналов – сначала создаются новые журналы (возможно, в новом db-пространстве(ах) ), а затем удаляются старые. Администрировать логические журналы можно с помощью onparams, GUI-программ или SQL API. Для добавления логических журналов используются следующие флаги:

-a –d имя_db_пространства – имя db-пространства, где будет находиться логический журнал

-s размер_журнала в килобайтах. Новый размер логического журнала. Требуется в том случае, когда новый журнал будет больше или меньше, ечм значение по умолчанию для экземпляра.

-i(опционально). Определяет, что новый журнал будет вставлен сразу после текущего, а не в конец цепочки журналов.

Если вы не укажете размер нового журнала (флаг -s), то будет создан журнал размером LOGSIZE (параметр файла $ONCONFIG). Этот параметр определяет размер логического журнала по умолчанию и в версии IDS 11.5 равен 10 Мбайт. В предыдущих версиях размер журнала по умолчанию различался. Размер журнала зависит от количества пользователей и характера их работы. Если одна или несколько таблиц содержат простые BLOB-объекты (типа TEXT или BINARY), журнал маленького размера практически не имеет смысла. Процесс записи в простое BLOB-поле обходит некоторые механизмы экземпляра и проводится непосредственно в логический журнал. Операция «insert» для BLOB-а не считается подтвержденной до тех пор, пока весь BLOB не записан в логические журналы. Удаление BLOB-объекта считается неподтвержденным до тех пор, пока журнал, в котором зарегистрирована эта транзакция, не архивирован на диск. В зависимости от количества и размеров BLOB-ов в логичесике журналы может записываться очень

большое количество информации. Как результат, вы должны создать журналы достаточно большого объема, чтобы они не заполнялись практически сразу. Как говорилось выше, журналирование smart BLOB-ов определяется конфигурационным параметром LOGGING, используемом при создании или изменении sb-пространства. Из экземпляра могут быть удалены только те логические журналы, в которые в данный момент времени не записываются транзакции и в которых не содержится информация о последней контрольной точке. Удаление логического журнала подразумевает использование его физического номера, а не logical ID. Каждый журнал имеет свой неизменяемый физический номер, а также логический номер, присваиваемый ему в тот момент, когда он становится «текущим» журналом экземпляра. Когда этот журнал заполняется, сервер БД инкрементирует логический номер этого журнала. Для определения физического номера каждого журнала , текущего журнала экземпляра и журнала, содержащего последнюю контрольную точку, используется команда onstat –l (строчная буква l). Для удаления логического журнала используется утилита onparams со следующими флагами:

-d –l физический_номер_журнала – определяет физический номер удаляемого логического журнала

-y – подтверждение удаления. Как и в случае физического журнала, я настойчиво рекомендую после администрирования логических журналов создавать полный архив экземпляра. Также необходимо обратить внимание на количество журналов и размер журнала. Если размеры журналов очень маленькие, то журналы будут быстро заполняться. Маленький журнал архивируется быстрее, однако при маленьком журнале гораздо легче получить ошибку длинной транзакции. Параметры LTXHWM, LTXEHWM определяют, какой процент логических журналов может быть заполнен перед началом отката открытой транзакции или перед остановкой других операций экземпляра для подтверждения такой транзакции или завершения ее отката. С другой стороны большие журналы медленнее заполняются. В результате они не архивируются на протяжении некоторого времени. В случае отказа оборудования вы будете разворачиваться из архива экземпляра и архива логических журналов. Если у вас в течении дня заполнялся один журнал, то возможности восстановления будут ограничены, особенно если этот журнал находился на сбойном диске. Можно подобрать размеры журналов так, чтобы они архивировались каждые 30-45 минут при средней активности экземпляра. В Части 7 мы рассмотрим автоматическое архивирование заполненных логических журналов. Автоматический запуск и остановка IDS Если вы такой же ленивец, как и я, то первое, о чем подумаете, это автоматизация остановки и запуска экземпляров. На Linux/Unix/Mac OS X я используя для решения этой задачи стартовые скрипты системы. На Linux/Unix серверах в каталогах rc2.d и rc0.d я размещаю скрипты start_ids (Листинг 5.1) и stop_ids (Листинг 5.2) для автоматического запуска и остановки экземпляра во время остановки или перезагрузки сервера. Обычно эти каталоги находятся в каталоге /etc, но в некоторых версиях Linux/Unix они расположены в /sbin.

##start_ids ## скрипт для запуска экземпляров IDS во время загрузки сервера ##Положить в каталог rc2.d и назначить правильный номер ## автор Carlton Doe export INFORMIXDIR= ##подставить путь к двоичным файлам IDS export PATH=$INFORMIXDIR/bin:$PATH echo “About to start IDS instances” echo “Starting instance_name” # заменить instance_name именем экземпляра export ONCONFIG= ##конфигурационный файл экземпляра export INFORMIXSERVER= ##DBSERVERNAME oninit ##повторить четыре предыдущие строки для всех экземпляров IDS ## при необходимости, если используются разные версии IDS ## изменить переменную окружения $INFORMIXDIR Листинг 5.1 Скрипт start_ids ##stop_ids ## скрипт для остановки экземпляров IDS во время выключения сервера ##Положить в каталог rc0.d и назначить правильный номер ## автор Carlton Doe export INFORMIXDIR= ##подставить путь к двоичным файлам IDS export PATH=$INFORMIXDIR/bin:$PATH echo “Shutting down IDS instances” echo “Stopping instance_name” # заменить instance_name именем экземпляра export ONCONFIG= ##конфигурационный файл экземпляра export INFORMIXSERVER= ##DBSERVERNAME onmode –ky ##повторить четыре предыдущие строки для всех экземпляров IDS ## при необходимости, если используются разные версии IDS ## изменить переменную окружения $INFORMIXDIR Листинг 5.2. Скрипт stop_ids Цифры в именах каталогов относятся к уровню исполнения ОС. Уровень 0 – это уровень остановки сервера, уровень 2 – первый многопользовательский режим. Скрипты в каталоге rc0.d выполняются в числовом порядке (перед номером скрипта ставится заглавная буква К - kill). Скрипты в каталоге rc0.d выполняются в числовом порядке (перед номером скрипта ставится заглавная буква S - start). Вы можете использовать любую буквенно-цифровую комбинацию, например, S95_start_ids. Я обычно стараюсь при остановке сервера остановить экземпляр как можно раньше. Это помогает остановить экземпляр IDS до начала остановки других систем сервера. Для скрипта старта сервера я наоборот стараюсь выбрать номер побольше. Это позволяет запуститься другим демонам и выделить этим демонам необходимую для работы память. На системах Mac OS X скрипт ibm.Informix.ids11.plist располагается в каталоге /Library/LaunchDaemons и автоматически запускает/останавливает экземпляр IDS во время перезагрузки сервера.

На Windows-системах самый простой метод обеспечить автоматический запуск/останов экземпляра – это разрешить службам экземпляра стартовать и останавливаться автоматически во время перезагрузки сервера. В Панель управления > Службы для служб экземпляра установите тип запуска «Автоматически». Обратите внимание, что в окне ввода пароля необходимо установить правильный пароль для учетной записи informix. Если пароль этой учетной записи будет изменен, например, из-за устаревания пароля, то необходимо будет обновить и пароль в этом поле. Контроль доступа и безопасность При настройке экземпляра необходимо уделить внимание вопросам безопасности и контроля доступа. Во-первых, подумайте, необходим ли пользователям доступ ко всем таблицам базы или только к определенным. При ответе на этот вопрос необходимо знать, могут ли пользователи подключиться к физическому серверу с помощью программ для администрирования или только с помощью определенных приложений. В IDS поддерживается контроль доступа на основе «ролей», с помощью которого вы можете ограничить доступ пользователю на основе его идентификатора (user ID). Хотя роли были и в предыдущих версиях IDS, но там было необходимо применять их как часть процесса инициализации сессии. В IDS 10 IBM усовершенствовала механизм ролей возможностью назначения пользователю «роли по умолчанию» (default roles). Эта роль активируется при подключении пользователя. Этот функционал включает в себя использование нового ключевого слова default в команде назначения роли. Давайте рассмотрим пример create role hr; create role it_dept; revoke all on employee from public; grant all on employee to hr; grant default role hr to susan; grant default role it_dept to Melinda После выполнения этих команд доступ к таблицы employee будет только у членов группы hr. Членство пользователя в роли проявляется при его подключении к базе данных, поэтому только Susan сможет читать и редактировать записи в таблице employee. Второй вопрос, на который необходимо ответить, - кто имеет право создавать базы данных. С помощью параметра DBCREATE_PERMISSION файла $ONCONFIG вы можете разрешить создавать базы данных только пользователю informix. По умолчанию этот параметр оставлен пустым, что позволяет создать базу данных любому пользователю. Этот список можно ограничить, задав в вышеуказанном параметре идентификаторы тех пользователей (user ID), которые имеют право создать БД. Третий вопрос – хотите ли вы контролировать возможность создавать UDR на С и/или Java. Поскольку эти объекты считаются внешними по отношению к серверу БД и выполняются вне контроля сервера, то при некорректном их написании могут представлять опасность для работы сервера БД. Чтобы контролировать создание таких процедур, необходимо выполнить два шага. Во-первых, необходимо установить параметр IFX_EXTEND_ROLE файла $ONCONFIG равным 1 – это включить функционал использования ограничений. По умолчанию этот параметр включен (значение 1), для выключения установите его равным 0. Во-вторых, назначьте роль extend тем пользователям, которым необходимо создавать или администрировать внешние UDR.

Этот же механизм контролирует, кто может регистрировать DataBlad’ы в системе. Только пользователь Informix и пользователю, которым назначена роль extend могут регистрировать DataBlade. Здесь я кратко рассмотрел только базовые вопросы безопасности экземпляра. во второй книге мы рассмотрим эти вопросы более подробно. Отстрел пользовательской сессии. Иногда возникает необходимость прибить подключение пользователя к экземпляру. Одно из преимуществ архитектуры Informix – отсутствие отдельного системного процесса обслуживания каждого пользовательского подключения. Крайне нежелательно убивать пользовательский поток, находящийся в критической секции. Критическая секция – часть кода Informix Dynamic Server, которая обрабатывает завершение транзакции и отслеживает, чтобы были выполнены все дисковые операции. Уничтожение такого потока ведет к немедленному откату транзакции. Если откат невозможен, экземпляр немедленно прекращает работу. Для определения того, находится ли поток в критической секции, используется команда onstat –u. Если в столбце флагов (flags) есть символ Х, это значит, что поток находится в критической секции. Вывод команды onstat –u показывает все пользовательские сессии экземпляра. Более подробные данные об отдельной сесии можно получить с помощью вызова команды onstat –g sec идентификатор_сессии. Также можно воспользоваться ОАТ и Server Studio. Пользовательская сессия отстреливается путем вызова команды onmode –z идентификатор_сессии, где идентификатор_сессии берется из столбца sessid вывода утилиты onstat –u. Для прерывания сессии, участвующей в распределенной транзакции, используется вызов onmode –Z. Распределенные транзакции и использование onmode –Z будут подробно рассмотрены во второй книге. Заключение В этой части мы рассмотрели типичные задачи администрирования Informix Dynamic Server. Незатронутыми остались вопросы настройки и мониторинга экземпляра. вопросы настройки мы будем рассматривать на протяжении всей книги, когда будем обсуждать тот или иной механизм СУБД и его настройку. Утилиты мониторинга рассмотрим в Части 8. Сейчас вы должны понимать режимы работы экземпляра Informix и уметь переводить экземпляр в он-лайн и офф-лайн; знать разницу между журналируемым и нежурналируемым режимом базы данных. Вы должны уметь создавать и удалять db-пространства, простые/smart BLOB-пространства, понимать разницу между регулярными и временными пространствами. Наконец, вы должны уметь перемещать логический и физический журнал, а также безопасно прибивать пользовательскую сессию. При выполнении этих базовых административных задач помните о следующем:

команду изменения режима работы экземпляра отменить нельзя изменение режима журналирования на нежурналируемый делает возможными

массовые изменения без возможности возникновения длинной транзакции. Вы можете перевести таблицу в сырой режим для выполнения административных операций и оставить другие таблицы доступными для пользователей.

После больших изменений экземпляра или баз данных создавайте архив 0-го уровня

Если база данных находится в журналируемом режиме, то изменения в созданным пользователем временных таблицах также журналируются. Избежать этого журналирования можно создав временную таблицу с

использованием ключевого слова with no log или установкой параметра TEMPTABLE_NOLOG.

Для хранения временных таблиц создайте несколько временных db-пространств.

Для равномерного распределения дискового ввода/вывода переместите логический и физический журнал из корневого db-пространства в другое пространство.

Перед отстрелом пользовательской сессии, с помощью команды onstat –u проверьте, чтобы эта сессия не находилась в критической секции. Для отстрела сессии используйте команду onmode –z идентификатор_сессии.

В следующей части мы рассмотрим некоторые задачи, которые должен решать администратор БД в сконфигурированном экземпляре. Мы поговорим о создании баз данных, таблиц и индексов. Я расскажу о фрагментировании таблиц и индексов, разнице между индексами и ограничениями и их использовании. Будут также представлены некоторые полезные SQL-запросы.

Часть 6. Создание окружения базы данных.

В этой части:

Создание баз данных, таблиц, индексов Использование фрагментирования Использование ограничений и индексов Загрузка данных Контроль доступа к данным Новые и/или обновленные SQL-команды

Большинство тем в этой книге относятся к администрированию экземпляров Informix Dynamic Server. В этой части мы рассмотрим вопросы администрирования базы данных и влияние механизмов IDS на него. Мы поговорим о создании баз данных и таблиц, фрагментировании, наполнении таблиц данными, а также рассмотрим некоторые полезные SQL-запросы. При выполнении задач администрирования я предпочитаю выполнять команды администрирования (в том числе и DDL-запросы) с помощью программы dbaccess. Давайте кратко рассмотрим использование этой программы и выполнение с ее помощью задач, обсуждаемых в этом разделе. Утилита dbaccess Это одна из самых главных программ, которые администратор Informix использует в своей работе. После внедрения в IDS 11 SQL API dbaccess может вообще быть практически единственной и достаточной программой администрирования. В Windows-версиях Informix вы можете использовать dbaccess с консоли физического сервера или подключившись к этому серверу через telnet. Программа dbaccess имеет 6 элементов меню:

Язык запросов (Querylanguage) Соединение (Connection) База данных (Database) Таблица (Table) Сессия (Session) Выход (Exit)

В таблице 6.1 описаны элементы каждого пункта меню. Подчеркнутые заглавные буквы показывают, как быстро вызвать команду

Меню утилиты dbaccess

Первичное меню

Вторичное меню

Третичное меню описание

Query language

New Run Modify Use_editor Output Choose Save Info Drop Exit

В Output доступны Printer New-file Append-file To-pipe

Эти меню используются для написания и выполнения SQL-запросов. По умолчанию вывод результатов запроса происходи в окно программы

Connection

Connect Disconnect Exit

Используется для подключения к базе экземпляра и отключения от нее. При отсоединении необходимо ответить на запрос подтверждения

Database Select Create Info Drop cLose Exit

Используется для получения информации о базах данных экземпляра и для подключения к ним. Подменю опции Create подробно рассматриваются ниже

Table Create Alter Info Drop Exit

Используется для получения информации о таблице, а также для создания, изменения, удаления таблиц в текущей БД. Подменю опции Create подробно рассматриваются ниже

Session Используется для получения базовой информации о текущей сессии dbaccess и ее подключении к экземпляру

Exit Выход из dbacess

Режимы журналирования базы данных Как я писал в 5 части, изменения данных в базе могут журналироваться на диске для обеспечения целостности данных в случае проведения операции восстановления. Ведение (или нет) таких журналов и определяет режим журналирования Если база данных журналируемая, сервер БД использует физический и логический журнал для записи изменений данных. Базы данных, расположенные на одном экземпляре IDS, могут использовать разные режимы журналирования. Режим журналирования базы указывается при ее создании, но может быть изменен в любой момент, как вы видели в Части 5. пользовательская сессия может изменить режим журналирования своих операций с помощью SQL-команды set log. Пользователи, имеющие право на изменение базы данных или таблиц, могут изменить режим журналирования отдельной таблицы или нескольких таблиц. Ниже мы рассмотрим эту возможность подробнее. В IDS поддерживаются четыре режима журналирования. Два из них очень похожи друг на друга и отличаются тем, когда буферы логического журнала сбрасываются на диск. Первый режим, нежурналируемый, записывает очень мало данных в логические журналы. Записываются только DDL-операции (create/drop table, create/drop index, create/drop procedure, rename table/column, alter table и т.п). Нежурналируемые базы данных обладают повышенной производительностью, поскольку на журналирование не тратятся ресурсы. Но в случае сбоя изменения в БД восстановить невозможно. После перезагрузки будут доступны только данные, которые были записаны в неповрежденные таблицы. Восстановление нежурналируемых баз данных ограничивается восстановление последнего полного архива экземпляра. Режим журналирования ANSI очень похож на небуферизированное журналирование (обсуждается дальше), но также предполагает совместимость с обработкой транзакций по ANSI. Совместимость с ANSI включает в себя такие возможности и правила как уникальное именование владельца табличных ссылок (unique owner naming for table references), различные значения по умолчанию для разных прав на таблицу (different defaults for table-level privileges), разницу в возможностях чтения и обновления для курсоров (differences in the update and read capability of cursors), разницу реагирования символьных и типов и типов с плавающей запятой на переполнение. Обратите внимание, что IDS не обеспечивает полной поддержки всех ANSI-стандартов. Если вы в ANSI-совместимой БД выполняете не-ANSI SQL-команду, то будет выдано предупреждение, и выполнение команды продолжится. Использование этого режима журналирования больших преимуществ не приносит. Небуферизированное и буферизированное журналирование работают практически одинаково, за исключением определения момента времени, когда буферы журнала сбрасываются на диск. DDL-операции журналируются в обоих режимах. Также журналируются операции insert, update, delete. Операции select не журналируются. Для журналирования операций select есть одно исключение: выражения select into temp могут журналироваться – это зависит от настроек экземпляра. Если запрос извлекает для обработки большой набор данных для обработки, то журналирование операций select into temp может вызвать сложности. Самый лучший способ избежать таких проблем – создавать временные таблицы во временном db-пространстве, используя ключевые слова with no log или установить в файле $ONCONFIG параметр TEMPTABLE_NOLOG. В Части 5 приведены дополнительные данные о создании временных db-пространств. Разница этих режимов журналирования заключается в записи журналируемых данных в журнал на диске. При небуферизированном журналировании буферы физического и логического журнала записываются на диск сразу после подтверждения транзакции. При буферизированном журналировании данные в буферах логического и физического журнала хранятся до момента полного заполнения этих буферов, обработки контрольной точки или если пользовательское соединение закрылось и транзакции не были записаны в журналы. Еще при одном условии может быть запущен сброс буферов на диск.

Поскольку в экземпляре может быть только один набор журналов, то в том случае, когда в базе данных с небуферизированным журналированием подтверждается транзакция, информация из буферов логического журнала записывается в журнал. (короче говоря, если БД с небуферизированным журналированием пишет в журнал, то в этот же момент времени в журнал сбрасываются и буфера логического журнала БД с буферизированным журналированием). Каждый из этих режимов журналирования имеет преимущества и недостатки. При небуферизированном журналировании целостность данных может быть гарантирована вплоть до отдельной транзакции, даже в случае критического сбоя экземпляра. но в этом режиме из-за постоянной записи в журнал, возрастает дисковый ввод/вывод. Кроме того, логические журналы заполняются быстрее, чем при буферизированном журналировании. При буферизированном журналировании уменьшается дисковый ввод/вывод, и экземпляр работает быстрее. Но поскольку информация о транзакциях хранится в разделяемой памяти, есть риск ее потерять при освобождении разделяемой памяти из-за катастрофического сбоя экземпляра. Малькольм Велланс (Malcolm Weallans), администратор IDS, с которым я очень давно знаком, сказал мне однажды: «Разница между буферизированным и небуферизированном журналированием – твоя паранойя». В очень немногих системах можно допустить потерю подтвержденных транзакций, поэтому обычно я использую небуферизированное журналирование. Исключением являются большие OLAP-системы, где очень мало транзакций и практически нет необходимости в журналировании. При выборе режима журналирования примите во внимание следующие факторы:

Изменчивость данных Требуемая производительность БД Допустимость потери отдельных транзакций Возможность пересоздать отдельные транзакции.

Создание базы данных. Существует два мнения о том, где создавать базу данных. Первая школа рекомендует создавать БД в корневом db-пространстве, вторая – где угодно, но только не в корневом. Я придерживаюсь второго мнения, поскольку в корневом db-пространстве и так находится множество системных таблиц, а также там по умолчанию создаются временные таблицы. Корме того, если при создании таблицы не указано, в каком db-пространстве ее создавать, она создается именно в корневом. В результате можно просто переполнить корневое db-пространство и положить экземпляр. Создать базу данных можно четырьмя путями: с помощью dbaccess, с помощью dbimport, с помощью SQL (через dbaccess) или с использованием Server Studio. При создании базы данных необходимо указать db-пространство, в котором она создается, и режим журналирования. Давайте рассмотрим некоторые методы создания подробнее. Создание базы данных с помощью dbaccess Выбор в dbaccess меню Database > Create проведет вас через процесс создания базы данных. После ввода имени БД вам будет предложено выбрать db-пространство и режим журналирования. Пункт Database > Create > Dbspace предоставляет возможность выбрать необходимое db-пространство, по умолчанию предлагается корневое db-пространство (rootdbs). Выберите необходимое пространство и нажмите «Enter». Пункт Database > Create > Log позволяет выбрать необходимый режим журналирования. По умолчанию используется «None» (нет журналирования). Если в двух вышеперечисленных меню ничего не выбрать, то база данных будет создана с параметрами по умолчанию. После выхода из Database > Create вам будет предложено создать БД (по умолчанию)

или отказаться от этого. После создания база данных становится «текущей» или «активной» базой данных в сессии dbaccess. Создание базы данных с помощью dbimport Этот метод создает не только базу данных, но и таблицы, индексы и ограничения. Затем утилита заполняет базу данных данными исходной БД из файлов в ASCII-формате, находящихся на диске или ленте. Обратите внимание, что Informix Dynamic Server рассматривает сессию dbimport как одну транзакцию. Если вы установите флаг создания журналируемой БД и в базу данных необходимо загрузить много данных, то вероятнее всего получите длинную транзакцию и импорт будет отменен. Я рекомендую не устанавливать флаг журналирования при использовании dbimport. Изменить режим журналирования можно в любой момент, как показано в Части 5. При создании БД с помощью dbimport выбор целевого db-пространства и режима журналирования осуществляется с помощью соответствующих флагов. Давайте рассмотрим параметры вызова команды dbimport имя_бд –d целевое_db_пространство [-l | -l buffered | ansi] Флаг –l (строчная буква L) определяет использование небуферизированного журналирования, флаг –l buffered – буферизированного журналирования. Если не указать режим журналирования, база данных создается как нежурналируемая. Если не указать целевое db-пространство, база данных будет создана в корневом db-пространстве. Ниже приведена полная синтаксическая диаграмма этой команды: dbimport имя_бд –d целевое_db_пространство [-l | -l buffered | ansi] [-I directory_name | -t tape_dev [-b blksize -s tapesize ] [-f path_to_file] У вас есть две возможности, чтобы указать утилите, где искать командный файл SQL и данные. Они могут быть на диске или ленте. Если файлы расположены на диске, используйте флаг –i и укажите полный путь к каталогу. Обратите внимание, что целевой каталог должен иметь такое же имя, как и тот из которого вы импортируете БД, и суффикс .exp. Если данные находятся на ленте, используйте опцию –t и, если экспорт проводился с параметрами, отличными от установленных для TAPEDEV, укажите размер блока и длину ленты. При экспорте БД на ленту вы можете выбрать, где хранить командный файл создания таблиц и индексов. Он может быть также записан на ленту в процессе экспорта либо перенаправлен в файл. Я обычно сохраняю его в файл. Для указания файла SQL-команд на диске используйте флаг –f и полный путь к файлу. Создание базы данных с помощью SQL Использование SQL и dbaccess – самый быстрый способ создать базу данных. Если вы запустили dbaccess без указания базы данных и выбрали Query > New, то автоматически будет выведено окно, в котором вам предложат выбрать базу данных. Закройте это окно (обычно Ctrl+C) и вернитесь в экрану Query > New. SQL-запрос вполне прост и понятен: create database имя_бд [in имя_db_пространства] [with log | with buffered log | log mode ansi]

Если ничего не указывать, то база данных будет создана в корневом db-пространстве без журналирования. В следующем примере создается база данных chap6_db в db-пространстве dbs_0 с небуферизированным журналированием. create database chap6_db in dbs_0 with log Создание и фрагментирование таблиц и индексов После создания базы необходимо создать таблицы, где будут храниться данные. В этом разделе мы рассмотрим создание таблиц, балансирование ввода/вывода и повышение производительности. Создание таблиц и индексов Таблицы и индексы могут быть созданы теми же 4-мя методами, что и базы данных. Программа dbimport для создания таблиц и индексов целевой базы данных использует командный файл. Если при экспорте БД был указан флаг –ss (server-specific), то во время импорта будет использована информация о расположении db-пространств, размере экстентов таблиц, обновлении статистики. Если необходимо изменить расположение таблиц или размер перед импортом базы, то вы можете отредактировать командный файл. Не изменяйте информацию о столбцах (например, имена столбцов) в командном файле, иначе во время импорта есть шанс получить ошибки (например, несовпадение типов). По умолчанию таблицы создаются в том же db-пространстве, что и база, используется страничная блокировка, размер таблицы равен 16 Кбайт (Linux/UNIX) или 32 Кбайт (Mac OS X/Windows). Режим блокирования таблицы можно поменять с помощью двух параметра файла $ONCONFIG DEF_TABLE_LOCKMODE и переменной окружения IFX_DEF_TABLE_LOCKMODE. Если вам необходимо установить режим блокировки для всего экземпляра, то лучше использовать конфигурационный параметр, если необходимо установить этот режим на уровне отдельной сессии – предпочтительнее использовать переменную окружения. Переменная окружения может быть установлена в сессии, которая запускает экземпляр, и тогда до перезапуска экземпляра будет использовано именно это значение переменной окружения. Установка конфигурационного параметра или переменной окружения не будет влиять на режим блокировки уже созданных таблиц, а только на создаваемые после установки параметра или переменной окружения. Ниже я расскажу, как изменить режим блокирования уже созданной таблицы. При создании таблицы через dbaccess после указания определения столбцов можно указать db-пространство, в котором создается таблица, размер экстента, режим блокирования и фрагментирование. С помощью dbaccess можно также создавать ограничения и индексы, но, как мне кажется, этот процесс достаточно запутан, и проще использовать SQL-команды. SQL-команды создания таблиц и индексов достаточно просты и понятны. Их синтаксис можно найти в IBM Informix Guide to SQL:Syntax. Я не буду подробно рассматривать синтаксис, а лучше расскажу о его применении. Мы не будем углубляться в вопросы проектирования схемы БД и нормализации, хотя от них во многом зависит стратегия фрагментирования. В этой части я буду пользоваться тестовой таблицей и индексами, код создания которых приведен в Листинге 6.1.

create table store_sales (division_no smallint, store_no smallint, category char(3), sales_date date, amt_sold decimal(8,2) ) in danube_1 extent size 550000 next size 5500 lock mode row; create index ix_strsls_div on store_sales (division_no) in idx_space_1; create index ix_strsls_cat on store_sales (category) in idx_space_2; create index ix_strsls_dt on store_sales (sales_date); Листинг 6.1 Таблица store_sales и ее индексы В синтаксисе создания таблицы необходимо обратить внимание на некоторые вещи. Прежде всего, ключевое слово in используется для указания db-пространства, в котором создается таблица (danube_1). Параметр extent size определяет, сколько места на диске в килобайтах выделить для таблицы при ее создании, параметр next size в килобайтах определяет, сколько места будет выделено таблице, когда заполнится первоначальный экстент. Как говорилось в Части 3, правильное определение размера таблицы очень важно для правильного проектирования базы данных. Без этого можно получить пересечение экстентов, что негативно сказывается на производительности. В приложении приведена схема вычисления размера начального и последующих экстентов на основе размера страницы db-пространства, длины строки и предполагаемого количества строк. Вы можете распределить индексы таблицы по разным db-пространствам, как это сделано с двумя первыми индексами в листинге. Вопрос фрагментации индексов мы рассмотрим ниже. В IDS 10 и 11 внесены новые возможности в процесс создания индексов. Давайте кратко рассмотрим эти улучшения. До этих версий процесс создания (удаления) индекса требовал эксклюзивного блокирования таблицы, т.е. до завершения процесса пользователи не могли получить доступ к таблице. Кроме того, созданный индекс напоминал хромую утку – оптимизатор знал, что индекс есть, но до выполнения update statistics для индекса, не использовал этот индекс при построении плана выполнения запроса. Выполнение update statistics также требует времени. В IDS 10 процесс создания индекса стал фоновым, и отпала необходимость блокирования таблицы. Индекс создается в «выключенном» состоянии. Когда создание индекса завершено, экземпляр включает индекс в тот момент, когда нет пользовательских сессий, обновляющих таблицу. Когда поступает команда удаления индекса, оптимизатор прекращает использование индекса для построения новых планов запросов, индекс удаляется, когда все существующие сессии прекращают его использование. В IDS 11 добавлена возможность построения статистики во время создания индекса, поэтому оптимизатор может начать использовать индекс сразу после его создания. Это не значит, что во время создания индекса выполняется оператор update statistics, разработчики IDS подошли к этой задаче значительно профессиональнее. При создании индекса сервер должен выполнить те же операции, что и при update statistics, - ему необходимо знать, сколько строк есть в таблице (update statistics low), нужно создать bins and overflows, также знать распределение данных в требуемых

столбцах (update statistics medium/high). В результате в конце процесса создания индекса информация update statistics low для индекса и update statistics high для ведущего столбца доступны оптимизатора для построения планов запросов. Создание статистической информации происходит автоматически, вам ничего не надо конфигурировать и настраивать. Статистическая информация собирается при создании индекса, при изменении таблицы, которое затрагивает индекс, и при изменении схемы фрагментирования индекса. В IDS 11 добавлен дополнительный функционал работы с индексами, который значительно снижает нагрузку на сервер при создании или изменении таблиц или индексов. В ранних версиях IDS если изменяемая таблица или индекс были частью UDR, написанной на SPL, или подготовленного выражения (prepared statement), то при доступе к таблице или индексу IDS возвращал ошибку –710. Приложение было должно еще раз подготовить выражение (would have to re-prepare the statement), а UDR, написанная на SPL, необходимо было переоптимизировать (re-optimized). В IDS 11 введен конфигурационный параметр AUTO_REPREPARE и переменная окружения IFX_AUTO_REPREPARE. Если установить значение этого параметра равным 1, то сервер будет проверять при построении плана запроса, не изменились ли таблица или индекс. Если изменились, то сервер автоматически переоптимизирует запрос или SPL-процедуру. Несмотря на то, что этот новый функционал уменьшает количество ошибок в приложениях, в некоторых случаях все равно может появиться ошибка –710. Первый случай – не будут переподготовлены выражения с DDL-операциями (типа alter table my_tab add col_34 smallint). Второй случай – если с изменяемой таблицей работает много сессий, то некоторые из них возможно сгенерируют ошибку. В этом случае необходимо перезапустить запрос. Необходимо понимать, что когда IDS выполняет переподготовку или ре-оптимизацию выражения, он работает на основе переменных окружения сессии. Т.е. если вы установили в сессии параметры PDQ priority, OPTCOMPIND, последовательность сортировки, то переподготовка/ре-оптимизация будет выполнена с учетом этих параметров. Такое поведение сервера может негативно повлиять на производительность работы. Дополнительные опции создания таблиц Начиная с IDS 9, при создании таблиц доступны дополнительные опции. В примерах ниже полагается, что таблица создается в стандартном режиме (standard mode). Большинство таблиц создается именно в стандартном режиме, поскольку этот режим гарантирует транзакционную целостность, использование ограничений, журналирование изменений. По умолчанию таблицы создаются именно в этом режиме. Но нужно знать, что таблица может быть создана в сыром режиме (raw mode). Сырые таблицы похожи на стандартные, за исключением того, что они не поддерживают журналирование изменений, ключи и ограничения целостности. В ранних версиях IDS для сырых таблиц не поддерживались индексы, но сейчас ситуация поменялась – оптимизатор может использовать индексы при работе с сырой таблицей. Пример создания сырой таблицы представлен в Листинге 6.2

create raw table store_sales ( division_no smallint, store_no smallint, category char(3), sales_date date, amt_sold decimal (8,2) ) in danube_1 extent size 550000 next size 5500 lock mode row; Листинг 6.2 пример создания сырой таблицы store_sales Если таблицы не содержат ограничений, то вы можете использовать alter table для перевода таблиц в сырой режим из стандартного или наоборот. В части 2 мы обсуждали объектно-реляционные возможности IDS. Сейчас Informix поддерживает тип данных row, который может состоять из полей разных типов. Вы можете использовать этот тип данных при создании простых или сырых таблиц, а также для создания производных таблиц, которые наследуют свойства мастер-таблицы или супер-таблицы. В Листинге 6.3 приведен пример создания двух «именованных» типов row и использования этих типов для создания таблицы, в которой хранится информация о студентах. Поскольку типы данных row определены, они могут использоваться во всей БД. create row type name_t (fname char(20), lname char(20)); create row type address_t ( street_1 char(20), street_2 char(20), city char(20), state char(2), zip char(9)); create table student (student_id serial, name name_t, address address_t, company char(30)); Листинг 6.3. Использование типов данных row для создания новой таблицы Второй путь создания таблиц – использование typed-таблиц. В Листинге 6.4 приведена иллюстрация этого метода. Вывод dbschema для такой таблицы покажет такие же имена столбцов и типы данных, как и для именованного типа row create row type student_info_t (fname char(20), lname char(20), street_1 char(20), street_2 char(20), city char(20),

state char(2), zip char(9)); create table student_info of type student_info_t; Листинг 6.4 Создание typed-таблицы Последняя опция, доступная при создании таблиц, - использование супер-типа, который используется для создания разных таблиц. В предыдущем примере мы создали тип данных student_info_t и таблицу на его основе. Теперь на основе student_info_t мы создадим новый тип данных, который наследует атрибуты student_info_t. create row type class_enrollment_t (course_no int, course_date date) under student_info_t; Используя новый подтип, создадим таблицу, которая наследует все атрибуты типа данных student_info_t. create table course_enrollment of type class_enrollment_t under student_info Такие таблицы наследуют все атрибуты супер-таблицы, включая фрагментирование, триггеры, индексы, ограничения и т.д. если в супер-таблицу после создания дочерних таблиц были внесены изменения, то эти изменения будут унаследованы дочерними таблицами. Фрагментирование таблиц. Одна из полезных возможностей Informix Dynamic Server – фрагментирование таблиц и индексов. Таблицы и индексы могут быть размещены в разных db-пространствах. В отличие от RAID 0, вы можете фрагментировать таблицы по определенным логическим правилам, что часто дает прирост производительности и надежности. Можно установить конфигурационный параметр DATASKIP, чтобы фрагментированные таблицы были доступны в том случае, когда недоступен одни из фрагментов. Как вы уже знаете, существует две схемы фрагментирования – round-robin и по выражению. Индексы могут фрагментироваться только по выражению. С помощью ключевого слова by expression вы можете разместить индексы в разных db-пространствах или в db-пространстве, отличном от того, где размещена таблица. Индекс можно оставить ко-резидентным (co-resident), т.е. он будет размещаться в том же db-пространстве, что и таблица. Вне зависимости от метода фрагментирования, необходимо помнить о влиянии роста экстентов на фрагменты и db-пространства. В Части 3 уже говорилось, что необходимо стараться правильно определить размеры таблиц, чтобы минимизировать пересечение экстентов и снижение производительности. Помните, что установки размера начального и последующих экстентов касаются всех фрагментов таблицы (за исключением тех, которые созданы с помощью описанного ниже приема). Все фрагменты таблицы будут созданы и будут расширяться на основе одинаковых настроек. Существует один способ создания фрагментов с разными начальными размерами. Сначала необходимо создать две или больше «псевдотаблиц» с идентичными схемами. Каждую таблицу создайте с разными значениями размера начального и последующих экстентов. Затем с помощью оператора alter fragment (описан ниже) создайте новую таблицу путем соединения вместе «псевдотаблиц». С помощью alter fragment измените условия фрагментирования.

С помощью этой методики можно создать таблицу, фрагментированную по разным db-пространствам, и где каждый фрагмент имеет свои собственные параметры роста. В IDS 10 был изменен процесс создания и администрирования фрагментов: можно создавать несколько фрагментов в одном db-пространстве. В ранних версиях каждый фрагмент должен был находится в отдельном db-пространстве, что ограничивало возможное количество фрагментов. С помощью ключевого слова partition можно полностью использовать преимущества больших db-пространств для хранения таблиц и преимущества фрагментированных таблиц. Давайте рассмотрим пример фрагментирования таблицы по этому методу create table store_sales ( division_no smallint, store_no smallint, category char(3), sales_date date, amt_sold decimal(8,2) ) fragment by expression partition part_1 (division_no=1) in danube_1, partition part_2 (division_no>7) in danube_1, partition part_3 (division_no>=5 and division_no<=6) in danube_2, partition part_4 (division_no>=2 and division_no<=4) in danube_3 extent size 5500 next size 250 lock mode row; Листинг 6.5 Размещение разных фрагментов таблицы в одном db-пространстве. Обратите внимание, что размещение всех фрагментов в одном db-пространстве негативно сказывается на производительности, так как доступ к диску сериализуется. Фрагментирование round-robin Эта схема фрагментирования предполагает, что вес данные таблицы будут равномерно распределены между всеми фрагментами таблицы. Если вы задаете эту схему фрагментирования для таблицы, в которой уже есть данные, то данные перераспределяться не будут. Они останутся на месте до тех пор, пока не будут выгружены (unload), удалены и загружены в таблицу снова. Эта схема фрагментирования обладает всеми преимуществами и недостатками RAID 0. При выполнении выборки из таблицы даже с учетом индекса экземпляр должен читать все db-пространства, содержащие фрагменты таблицы. В зависимости от размера таблицы, эта схема фрагментирования может обеспечить большую производительность, чем хранение таблицы в отдельном db-пространстве. При фрагментировании таблицы по round-robin, ее индексы не должны создавться как ко-резидентные. Если этого не сделать и создать индексы как ко-резидентные, то страниы индексов будут распределены по db-пространствам, в которых хранятся фрагменты таблицы, что вызовет значительное падение производительности из-за необходимости чтения всех индексных страниц в db-пространствах, содержащих фрагменты таблицы. Индексы фрагментированных по round-robin таблиц должны быть «отключены» (detached)и созданы в отдельном db-пространстве. В Листинге 6.6. показан пример создания таблицы с фрагментированием по round-robin

create table store_sales ( division_no smallint, store_no smallint, category char(3), sales_date date, amt_sold decimal(8,2) ) fragment by round robin in danube_1, danube_2, danube_3, danube_4 extent size 95000 next size 9500 lock mode row; Таблица store_sales с фрагментированием по round-robin Фрагментирование по выражению. Фрагментирование по выражению подразумевает, что данные таблицы или индекса разделяются по разным db-пространствам на основе логических правил. Правила можно создать используя выражения SQL и применить их при создании таблицы или в любой удобный момент времени. В выражении фрагментирования можно использовать практически любой столбец таблицы (некоторые исключения обсудим ниже). В отличие от алгоритма round-robin, применение фрагментирования по выражению к таблице с данными приводит к перераспределению этих данных в соответствии с правилом фрагментирования. В зависимости от режима журналирования базы и количества перемещаемых строк может случиться длинная транзакция. При изменении значений полей, которые используются в выражении фрагментирования, строка может быть также перенесена в другое db-пространство. Одна из самых приятных возможностей фрагментирования по выражению – возможность уменьшить количество индексов без потери производительности. Оптимизатор использует выражения фрагментирования для исключения из просмотра фрагментов, где не могут храниться необходимые данные. Давайте вспомним нашу тестовую таблицу и предположим, что у нас 6 отделов продаж, из которых реально работают 4. Мы можем построить схему фрагментирования так, чтобы данные по продажам 4 активных отделов продаж раскладывались по разным db-пространствам, а данные по 2 малоактивным отделам складывались в одно db-пространство. Такой подход позволяет не создавать индекс по номеру отдела продаж, поскольку данные уже разделены с помощью выражения фрагментирования. В Листинге 6.7 показано, как создать таблицу с фрагментированием по выражению create table store_sales ( division_no smallint, store_no smallint, category char(3), sales_date date, amt_sold decimal(8,2) ) fragment by expression division_no=1 in danube_1 division_no=2 in danube_2 division_no=4 in danube_3 division_no=5 in danube_4 (division_no=3) or (division_no=6) in danube_5 extent size 950 next size 95 lock mode row; Листинг 6.7. Таблица store_sales с фрагментированием по выражению

Приведенные выражения фрагментирования вполне просты и понятны, на практике могут использоваться сложные выражения с применением UDR или secondary access method operator classes. Первый метод очень полезен, если необходимо создать правила сложнее, чем «равно, больше/меньше». Использование UDR позволяет создавать схемы фрагментирования с использованием столбцов, созданных на основе определенных пользователем типов данных. UDR могут быть написаны на любом поддерживаемом языке, но должны всегда возвращать только булев результат. Использование secondary access method operator classes с точки зрения реализации похоже на использование UDR. Необходимо, чтобы класс оператор разрешался в формат индекса B-дерева (the operator class must resolve to a B-tree index format).исходя из этого вы выбираете опции класса, которые хотите использовать для построения схемы фрагментирования. Как вы понимаете, правила фрагментирования таблиц необходимо записывать правильно, чтобы IDS мог быстро определить, куда вставлять строку или где ее искать. Ниже мы обсудим эту мудрую мысль подробнее. Оценка выражения Сервер оценивает выражения фрагментирования сверху вниз и слева направо. Очень желательно, чтобы выражения фрагментирования были исключительными (чтобы одна строка не удовлетворяла двум и более выражениям). Если это не так, строка будет обработана в соответствии с первым подходящим правилом. В выражениях фрагментирования допускается использование всех столбцов таблицы, кроме столбцов с BLOB-ами. Я не рекомендую использовать в выражениях фрагментирования типы данных serial (и подобные), date, datetime, поскольку при их использовании распределение строк становится неравномерным, особенно если таблица не является статичной. Об одном исключении из этого совета я расскажу ниже. Если вы все-таки используете правила на основе этих типов, то вам придется часто переписывать правила для перераспределения данных. Корме того, использование типов данных date, datetime замедляет вычисление выражений, поскольку серверу необходимо для оценки выражения преобразовывать данные этих типов в целое. В случае если все-таки необходимо использовать фрагментирование по дате, IDS 11 предоставляет новый функционал, который позволяет использовать функции обработки дат (month(), year(), day()) в выражениях фрагментирования. С помощью этого подхода можно создать схему фрагментирования, которая не будет нуждаться в изменениях. fragment by expression month(sales_date)=1 in tagus_1 fragment by expression month(sales_date)=2 in tagus_2 fragment by expression month(sales_date)=3in tagus_3 fragment by expression month(sales_date)=4 in tagus_4 fragment by expression month(sales_date)=5 in tagus_5 fragment by expression month(sales_date)=6 in tagus_6 fragment by expression month(sales_date)=7 in tagus_7 fragment by expression month(sales_date)=8 in tagus_8 fragment by expression month(sales_date)=9 in tagus_9 fragment by expression month(sales_date)=10 in tagus_10 fragment by expression month(sales_date)=11 in tagus_11 fragment by expression month(sales_date)=12 in tagus_12 Использование функций обработки дат снимает проблему производительности, связанную с конвертированием дат в целое число, поскольку эти функции обрабатывают даты в их

родном формате. В функциях фрагментирования можно использовать любые функции SQL, включая функции mod() и pow(). Использование функции mod() (иногда называется вычислением хэша – hash expression) приводит к равномерному распределению строк таблицы, в которой уже есть данные. Это очень похоже на алгоритм round-robin, но использование этой функции SQL позволяет оптимизатор ускорить выборку необходимых строк даже при их равномерном распределении. Выражение фрагментирования выглядит примерно так: .. ., )fragment by expression mod(cust_id,3)=2 in danube_1 mod(cust_id,3)=1 in danube_2 mod(cust_id,3)=0 in danube_3 lock mode row; Выражения фрагментирования должны быть максимально простые, поскольку сервер вычисляет их каждый раз при добавлении строки или при ее изменении. При использовании в выражениях фрагментирования диапазонов (дат, чисел), самое исключающее выражение ставьте первым. Например: . ., region_code smallint )fragment by expression (region_code>=200) in danube_3 (region_code>=150) in danube_1 (region_code>=100) in danube_4, remainder in danube_5 Если задать порядок правил наоборот (т.е. первым поставить(region_code>=100) in danube_4 )), то практически все строки таблицы окажутся в db-пространстве danube_4. Единственным исключением будут строки с region_code<100 – они будут в db-пространстве danube_5. Это же правило справедливо и с в случае использования в выражениях фрагментирования диапазонов: наиболее исключающее выражение должно быть первым. ., trans_code smallint )fragment by expression (region_code>=50 and trans_code<100) in danube_2 (region_code>=25 and trans_code<50) in danube_3 (region_code>=1and trans_code<25) in danube_5 remainder in danube_1 Обратите внимание на использование ключевого слова remainder. На практике его необходимо избегать, поскольку оптимизатор всегда при выполнении запроса просматривает раздел remainder, даже если, благодаря выражениям фрагментирования, абсолютно ясно, в каких db-пространствах располагаются исходные данные. Вмсето использования remainder пишите выражения фрагментирования так, чтобы все строки, с атрибутами вне правил фрагментирования, складывались в определенное db-пространство. Например, можно написать так:

.

., region_code smallint )fragment by expression (region_code>=200) in danube_3 (region_code>=150) in danube_1 (region_code>=100) in danube_4, (region_code<100) in dbs_5 При такой записи оптимизатор не будет сканировать еще одно db-пространство. Фрагментирование индексов. В IDS 7 и младше страницы таблиц и индексов располагаются в экстентах таблиц. В IDS 9 и старше это поведение изменилось – индексы размещаются в своих собственных экстентах, даже если они были созданы в в том же db-пространстве, что и таблица. Вы можете фрагментировать индексы по выражениям. Фрагментирование по round-robin не поддерживается. Самый простой пример – создание индекса в db-пространстве, отличном от db-пространства, где находится таблица. Например: create index ix_strsls_cat on store_sales (category) in idx_space_1; create index ix_strsls_dt on store_sales(sales_date) in idx_space_2; Размещение индексов отдельно от таблицы может существенно повысить производительность. Я всегда стараюсь размещать индексы в db-пространствах на тех дисках, где находятся db-пространства с таблицами, к которым пользователи обращаются редко. Если вам необходимо разместить самые активные по вводу/выводу таблицы по всем дискам, то не забудьте также по всем дискам разместить и самые активно-используемые индексы. Для построения схемы фрагментирования индексов вы можете применять любой столбец, используемый в индексе. Правила фрагментирования индексов обрабатываются точно также, как и правила фрагментирования таблиц, поэтому советы из предыдущего раздела применимы и к индексам. Вот пример неправильной идеологически, но правильной синтаксически схемы фрагментирования: create index major_idx on store_sales (division_no, store_no, category) fragment by expression division_no >4 in danube_index_1, category=”A” or category=”F” in danube_index_2, division_no <=4 in danube_index_3; В отличие от таблиц, для фрагментированных индексов нельзя задать размеры экстентов. IDS самостоятельно выделяет необходимые экстенты. Изменение фрагментирования. Изменить фрагменты таблиц или индексов можно в любой момент с помощью SQL-команды alter fragment. С помощью этой команды вы можете переинициализировать фрагментирование, удалить, добавить фрагменты. Можно также слить две одинаковые по структуре таблицы в одну фрагментированную. С помощью этой команды можно отключить фрагмент таблицы для создания новой таблицы. В этом разделе мы, в основном, будем говорить о фрагментах таблиц. Нижеизложенные принципы можно

применить и к изменению фрагментов индексов, по я предпочитаю удалять и пересоздавать индексы с нужной схемой фрагментирования. В разделе 11 IBM Informix Dynamic Server Administrator’s Guide приведены команды SQL, которые журналируются всегда, вне зависимости от режима журналирования базы, на которой выполняются эти команды. Команда alter fragment присутствует в этом списке. Поэтому перед запуском команды убедитесь, что в логических журналах сервера достаточно места для поддержки выполнения этой операции и других операций в БД. Это значит, что нужно убедиться, что параметры LTXHWM и LTXEHWM соответствуют размеру логических журналов экземпляра, которые могут быть использованы перед инициализацией ситуации длинной транзакции. Перед выполнением этой команды стоить включить автоматическое добавление логических журналов. После завершения выполнения операции не забудьте удалить лишние журналы. Обратите внимание, что команду alter fragment нельзя выполнять для активной таблицы, так как эта операция выполняется в одной транзакции, и при выполнении этой команды таблица блокируется в эксклюзивном режиме. Если какая-то сессия использует таблицу, команда изменения фрагмента (alter fragment) будет отменена. А во время выполнения команды все запросы к таблице будут отвергнуты. При выполнении команды все старые фрагменты таблицы находятся на своих местах до тех пор, пока не будут окончательно созданы новые фрагменты и синхронизированы индексы. Только после этого старые фрагменты будут удалены. Это приводит к тому, что во время выполнения этой операции наблюдается эффект «двойного использования дискового пространства», т.е. таблица занимает в 2 раза больше дискового пространства. В случае отката транзакции новые фрагменты будут удалены, а старые активированы заново. Перед изменением фрагмента убедитесь, что в db-пространстве достаточно места для хранения и новых, и старых фрагментов. Инициализация, добавление и изменение фрагментов. Для иллюстрации выполнения команды alter table используем таблицу store_sales, созданную в начале этой части. Чтобы сделать ее фрагментированной необходимо выполнить такие команды (в зависимости от выбранной схемы фрагментирования) alter fragment on table store_sales init fragment by round robin in danube_2, danube_3, danube_4; alter fragment on table store_sales init fragment by expression division_no=1 in danube_1, division_no=2 in danube_2, division_no=4 in danube_3, division_no=5 in danube_4, (division_no=3) or (division_no=6) in danube_5; В этих примерах показано использование ключевого слова init для переинициализации схемы фрагментирования с многими условиями. Это ключевое слово можно использовать и для удаления схемы фрагментирования. Для того, чтобы сделать таблицу не фрагментированной можно выполнить команду: alter fragment on table store_sales init in danube_7; В отличие от команды alter table, в одной команде alter fragment нельзя выполнить несколько действий. Следовательно, добавление фрагмента к таблице и изменение

выражения фрагментирования этой же таблицы требуют выполнения двух отдельных команд. Исключение из этого правила – использование ключевого слова init для переинициализации всей схемы фрагментирования. Например, изменение схемы фрагментирования: alter fragment on table store_sales modify danube_3 to ((division_no=4) or (division_no=3)) in danube_3, modify danube_5 to division_no=6 in danube_12; Вы можете использовать этот синтаксис, как показано в примере, для перемещения данных фрагмента в другое db-пространство. Для добавления новых фрагментов к существующей схеме фрагментирования можно использовать команды, похожие на нижеприведенные. Первая команда добавляет фрагменты к схеме фрагментирования по выражению, вторая – к схеме фрагментирования round-robin alter fragment on table store_sales add store_no>400 in danube_4; alter fragment on table store_sales add danube_6; Добавление фрагмента к схеме фрагментирования round-robin не вызывает перераспределения строк, которые уже есть в таблице. Новое db-пространство будет использовано для размещения новых строк. При изменении схемы фрагментирования вы можете с помощью ключевых слов before и after указать, где в схеме фрагментирования располагается новое правило. Единственное исключение - выражения фрагментирования нельзя указывать после ключевого слова remainder. Например, alter fragment on table store_sales add store_no>400 in danube_4 before danube_7; Удаление фрагментов При удалении фрагмента обязательно обратите внимание, куда денутся данные, расположенные в этом фрагменте. По умолчанию они перемещаются в фрагмент remainder, если таковой существует. Как я уже говорил фрагмента remainder лучше избегать из-за его негативного влияния на производительность запросов. Удаление фрагмента напоминает перемещение логических журналов из корневого db-пространства после настройки сервера. Сначала вам нужно изменить схему фрагментирования или добавить новые фрагменты. Затем перелить в эти фрагменты данные, которые расположены в фрагменте, который будет удаляться. Затем фрагмент можно удалить. Если новые условия фрагментирования не позволяют перенести строку из удаляемого фрагмента в другой, то будет сгенерирована ошибка SQL –776 и ошибка ISAM –772, и транзакция drop fragment откатится. Рассмотрим пример команды удаления фрагмента alter fragment on table store_sales drop danube_3 Если таблица была создана с несколькими фрагментами, которые расположены в одном db-пространстве, то при удалении фрагмента необходимо указать ключевое слово partition и имя фрагмента

alter fragment on table store_sales drop partition part_3 Чтобы убедиться, что правила фрагментирования написаны правильно, после изменения схемы фрагментирования я обычно с помощью dbschema создаю схему таблицы. Если это не так, то с помощью серии команд add, modify, drop fragment можно привести схему фрагментирования к необходимому виду. Для повторной инициализации всей схемы фрагментирования можно использовать ключевое слово init. Необходимо помнить, что повторная инициализация может привести к длинной транзакции, поэтому эту операцию лучше производить во время выполнения работ по обслуживанию БД. Перед проведением больших изменений схемы фрагментирования может быть полезно перевести таблицы в сырой режим. Этот метод позволяет снизить нагрузку на сервер при выполнении операции изменения схемы фрагментирования, но не позволяет выполнить восстановление в случае неудачи. После изменения таблицы и перевода ее назад в стандартный режим, необходимо выполнить архив 0-го уровня. Присоединение таблиц Используя ключевое слово attach в команде alter fragment, вы можете объединить две таблицы с одинаковой структурой в одну. «Новую» таблицу можно создать с фрагментированием по round-robin, тогда каждая таблица будет содержать свои прежние данные, или с помощью ключевого слова as задать схему фрагментирования и выполнить фрагментирование как часть операции attach. Каждая присоединяемая таблица сохраняет свои параметры экстентов. Поэтому перед присоединением таблиц необходимо убедиться, что в db-пространствах хватит места. Синтаксис присоединения выглядит так: alter fragment on table store_sales attach store_sales, midwest_sales; Вторая и последующие таблицы (в примере это midwest_sales) становятся «расходными» и теряют свои имена, первая таблица остается «выжившей» и сохраняет имя. Несколько замечаний по присоединению таблиц:

При соединении таблиц удалите все созданные ограничения. Попытка присоединить таблицы с ограничениями вызовет ошибки SQL –868 или –888

Таблицы со столбцами serial, serial8 не могут быть присоединены. К фрагментированной таблице могут быть подключены только

нефрагментированные таблицы. Все индексы «расходной» таблицы при присоединении ее к другой таблице

удаляются. В «выжившей» таблице журналируемой базы останутся индексы, и они будут применены для новой таблицы. В нежурналируемой БД оставшиеся индексы не будут применены к новой таблице – их необходимо удалить и создать снова.

Триггеры и представления «расходной» таблицы удаляются. Триггеры и представления «выжившей» таблицы остаются, но на время присоединения все триггеры отключаются.

При присоединении таблиц для создания схемы фрагментирования в правильном порядке вы можете использовать ключевые слова before и after.

Таблицы с типами данных неименованная строка (unnamed row) и именованная строка (named row) не могут быть присоединены.

Фрагменты подключенных таблиц должны находится в db-пространствах с одинаковым размером страницы.

Отключение фрагментов Вы можете выделить фрагменты из «первичной» таблицы, чтобы создать новые, «отключенные» таблицы. В зависимости от схемы фрагментирования, отключение фрагментов в новые таблицы может быть простым методом создания таблиц истории. С этой целью в схеме фрагментирования лучше использовать столбцы типа date или serial. Когда в таблицу начинают записываться данные с датами, большими, чем определенная, или когда размер таблицы становится больше заданного, вы можете добавить к таблице новый фрагмент, а деактивированный фрагмент отключить от первичной таблицы и переместить данные из него в новую таблицу истории. Отключенные таблицы наследуют параметры экстентов и режим блокирования первичной таблицы. Больше ничего не наследуется. Вам будет необходимо создать индексы, ключи и ограничения для новой таблицы. Синтаксис отключения таблиц предполагает задание имени db-пространства, где содержится отключаемый фрагмент, и имя новой таблицы. Например, alter fragment on table store_sales detach danube_5 div3_sales; Если фрагменты таблицы находятся в одном db-пространстве, то перед именем фрагмента необходимо указать ключевое слово partition. alter fragment on table store_sales detach partition part_5 div5_sales Изменение таблиц. Выше мы обсуждали вопросы физического хранения таблиц и индексов. Вторая большая часть администрирования таблиц – это модификация схемы. В этом разделе мы поговорим о определении столбцов, ограничениях и ссылочной целостности. Для модификации схемы таблицы и режима журналирования можно использовать SQL-команду alter table. В одной команде alter table вы можете выполнять несколько изменений таблицы. Это могут изменение режима блокировки, добавление, удаление, изменение столбца, изменение типа данных столбца, добавление или удаление опций безопасности, типа Label-Based Access Control, добавление или удаление идентификаторов строк (row ID) или контрольных столбцов Enterprise Replication/MACH-11. некоторые изменения могут быть выполнены «на месте» (in-place), другие требуют полной перестройки таблицы. Изменения «на месте» выполняются практически, не вызывают нагрузки на устройства ввода/вывода, но требуют мониторинга, особенно если выполняется несколько изменений структуры таблицы. Изменения «не на месте» (non-in-place alters) не требуют мониторинга, но вызывают на грузку ввода/вывода и выполняются некоторое время. Основные изменения такого типа – изменения типа данных столбца на несовместимый тип данных (например, изменение типа данных столбца с числового на символьный). Другие изменения такого типа – добавление/удаление идентификатора строки (row ID), удаление BLOB-столбца, изменение столбца, который используется в схеме фрагментирования таким образом, что часть данных необходимо перенести в другое место хранения. При выполнении таких изменений создается таблица с требуемой схемой, а затем данные из старой таблицы копируются в новую. На таблицу в этом случае накладывается эксклюзивная блокировка, которая предотвращает доступ пользователей к таблице. После заполнения данными новой таблицы старая будет удалена. Перед запуском операции такого типа необходимо убедиться, что в целевых db-пространствах достаточно места и для исходной таблицы, и для ее копии, в противном случае операция завершится ошибкой. Большинство операций изменения схемы таблицы выполняются «на месте». При выполнении таких изменений создается новая схема таблицы, но данные не сразу обновляются. Когда обновляется строка такой таблицы, то обновляется схема

строки так, чтобы соответствовать последней версии схемы таблицы. Пример показан ниже на Рисунке 6.2

my_table Row_1 Col_1 Col_2 Col_3 Col_4 Col_5 Row_2 Col_1 Col_2 Col_3 Col_4 Col_5 Row_3 Col_1 Col_2 Col_3 Col_4 Col_5 alter table my_table add (col_6 int) before col_3; insert into my_table values(….); insert into my_table values(… ); Row_1 Col_1 Col_2 Col_3 Col_4 Col_5 Row_2 Col_1 Col_2 Col_3 Col_4 Col_5 Row_3 Col_1 Col_2 Col_3 Col_4 Col_5 Row_4 Col_1 Col_2 Col_6 Col_3 Col_4 Col_5 Row_5 Col_1 Col_2 Col_6 Col_3 Col_4 Col_5 select col_2 from my_table where conditions=row_2; update my_table set col_1=”xyz” where conditions=row_1 Row_1 Col_1 Col_2 Col_3 Col_4 Col_5 Col_5 Row_2 Col_1 Col_2 Col_3 Col_4 Col_5 Row_3 Col_1 Col_2 Col_3 Col_4 Col_5 Row_4 Col_1 Col_2 Col_6 Col_3 Col_4 Col_5 Row_5 Col_1 Col_2 Col_6 Col_3 Col_4 Col_5 Рисунок 6.2 Изменения таблицы «на месте» и версионность схемы Во время изменения схемы в таблице my_table уже были данные. После изменения схемы в таблицу был вставлены две новые строки. Эти строки были вставлены с учетом нового формата таблицы, но все старые строки хранятся в старом формате. Затем одна строка была выбрана с помощью оператора select, а вторая была обновлена. Выборка строки не вызывает модификации ее схемы, а операция обновления – вызывает. Если вы выполните dbschema для этой таблицы, то команда вернет все столбцы, соответствующие последней «версии» схемы. Возникает вопрос – есть ли в таблице строки, которые не соответствуют последней «версии» схемы и как исправить ситуацию? На первый вопрос отвечает команда oncheck –pT. На второй – «делайте это, только если вам очень сильно нужно». В Листинге 6.8 показан вывод двух команд oncheck. В начале листинга представлен вывод oncheck для таблицы my_table, в конце – для другой таблицы Home Data Page Version Summary Version Count 0(oldest) 2 1(current) 3

Home Data Page Version Summary Version Count 0(oldest) 2 1 3 2 0 3 26 4(current) 3 Листинг 6.8 Часть вывода команды oncheck –pT – вывод версий строк

Как видите в таблице могут храниться строки различных версий. Обычно это не влияет на производительность. Когда выполняется выборка строки со старой схемой, IDS добавит в новые столбцы этой строки значения NULL. Если было произведено много изменений схемы и ваши приложения постоянно запрашивают «старые» данные, процесс модификации строк перед их возвращением клиентскому приложению может снизить производительность системы. Решить эту проблему можно довольно просто – обновите один из столбцов сам на себя, и все строки таблицы будут обновлены до самой последней версии схемы: update my_table set col_1=col_1; Перед выполнением операции такого типа убедитесь, что хватит места для хранения строк в последней версии схемы. Поскольку изменение таблицы выполняется как одна транзакция, необходимо быть уверенным, что вам хватит логических журналов для предотвращения ситуации длинной транзакции. При операциях «на месте» это не критично, поскольку данные таблицы не изменяются немедленно. Изменения «не на месте» более проблематичны, степень серьезности возможных проблем зависит от количества строк в таблице. Простейший метод решения – поменять режим журналирования таблицы на raw. О сырых (raw) таблицах было сказано выше. Изменения в этих таблицах не записываются в логические журналы, поэтому можно провести их различные изменения без риска возникновения длинной транзакции. Недостаток – невозможно выполнить откат изменений или восстановится после отмененных операций. Для выполнения изменений «не на месте» можно перевести таблицу в сырой режим, выполнить необходимые действия, а затем вернуть ее в обычный режим. Эта операция не повлияет на индексы таблицы. Такое поведение индексов может быть и желательным, и нет, в зависимости от числа перестроек индекса в результате изменений в таблице. Последовательные перестройки индекса могут существенно замедлить выполнение команды alter table. Я обычно при выполнении alter table удаляю все индексы, а затем создаю их заново. При таком подходе индекс перестраивается один раз. Ограничения, ссылочная целостность и индексы Обеспечение целостности данных в базе данных – одна из самых важных задач администратора БД. В решении этой задачи важную роль играют хранимые процедуры, определенные пользователем функции (UDR), триггеры, различные типы ключей. Давайте теперь кратко рассмотрим ограничения и индексы. Хранимые процедуры, определенные пользователем функции, триггеры заслуживаю не нескольких абзацев в книге, а отдельного рассмотрения. О хранимых процедурах можете почитать в IBM Informix Guide to SQL:Tutorial, а об определенных пользователем функциях – IBM Informix User-Defined Routines and Data Types Developer’s Guide. Хранимые процедуры, определенные пользователем функции (UDR) и триггеры

Хранимые процедуры – это функции, написанные на комбинации SQL и языка хранимых процедур (stored procedure language SPL). Процедуры хранятся в откомпилированном виде для каждого экземпляра и могут быть использованы для аудита таблиц, обеспечения безопасности, обработки данных и повышения производительности сервера. Хотя синтаксис хранимых процедур очень похож на синтаксис С, на самом деле он ограничен базовыми командами управления типа if-then-else, while, for. Остальная функциональность хранимых процедур унаследована от SQL. В IDS 11 введены новые операторы – loop, while loop, for loop, exit when, goto, маркированные циклы (marked loops). Определенные пользователем функции (User-defined routine UDR) – расширения встроенных процедур, написанных на SPL. Обычно термин UDR относится к процедурам, написанным на С или Java. Если UDR написанs на Java, они собираются в класс, а затем в .jar файл. После регистрации в экземпляре, .jar-файл хранится в одном из sb-пространств. В сервер БД для выполнения таких процедур интегрирована виртуальная машина Java. Если UDR написана на С, то ее необходимо скомпилировать, получить разделяемую объектную библиотеку (shared object library) и положить в каталог, владельцем которого является пользователь informix и права на который установлены как 755. Общепринятым является использование каталога вроде $INFORMIXDIR/extend, но вы можете использовать любой другой каталог в системе. Все UDR, написанные на С, должны лежать в одном каталоге, определенном в конфигурационном параметре DB_LIBRARY_PATH файла $ONCONFIG. Хранимые процедуры и UDR могут вызываться пользовательскими приложениями или триггерами. Поскольку UDR рассматриваются как объекты сервера БД при их разработке вы можете применять объектно-ориентированный подход. Например, можно создать перегруженную функцию (overloaded function). Перегруженная функция – это функция с тем же именем, что и существующая, но с другой сигнатурой. Например, create function convrt_val (in_1 dollar, in_2 aus_dollar)…. create function convrt_val (in_1 aus dollar, in_2 euro)… create function convrt_val (in_1 euro, in_2 aus_dollar)… Сервер БД при выборе, какую из перегруженных функций вызывать, будет ориентироваться на тип передаваемых в нее параметров. Одно из основных различий между UDR и хранимыми процедурами – хранимые процедуры выполняются на CPU ВП, а UDR могут быть сконфигурированы для выполнения на определенном пользователем ВП (user-defined VP UDVP) или ВП определенного класса. Одно из преимуществ IDS – возможность определить определенный пользователем ВП (user-defined VP UDVP). Определенные пользователем ВП – это псевдонимы ВП CPU-класса, но поскольку они элементами пользователя, а не экземпляра, следовательно, выполняются в ОС как процессы пользователя informix, а не root. Владельцем процессов экземпляра, благодаря использованию setuid, является пользователь root. Проблемой может стать исполнение UDR на ВП класса CPU. Так как UDR написана на Java/C, то ничего не препятствует ей вызвать функции ОС, выполняться которые будут с привилегиями root, что очень нежелательно с точки зрения безопасности, особенно если функция не была тщательно протестирована. Процесс связывания UDR с определенным UDVP довольно прост. Сначала вы создаете UDVP, используя параметр VPCLASS файла $ONCONFIG или команду onmode. Затем в команде регистрации UDR используете ключевое слово class

create function convrt_val (in_1 dollar, in_2 aus_dollar) class=”convrt_vp” external name “/opt/IBM/Informix/11_5/extend/cnvrt_funcs.so” language C not variant .. .. Триггеры, как и хранимые процедуры, тоже пишутся на смеси SQL и SPL и предоставляют похожие возможности. Пользователи не могут вызывать триггеры; экземпляр вызывает триггер, когда происходит действие, отслеживаемое этим триггером. Например, триггер может быть вызван после обновления строки в таблице. Вы можете, например, создать триггер, который вызывается при обновлении только определенного столбца таблицы. Часто триггеры в свою очередь вызывают хранимые процедуры или UDR. В ранних версиях IDS на таблицу мог быть создан один триггер на вставку, один на удаление и несколько триггеров на обновление. В IDS 11 можно иметь несколько триггеров на каждое действие над таблицей. Триггеры могут быть созданы для трех случаев – before, for each row, after. Когда на одну операцию создано несколько триггеров, они срабатывают в таком порядке – сначала триггер before, затем for each row, затем after. В этом случае не нужно беспокоиться о порядке срабатывания триггеров. Функционал триггеров также был существенно расширен в IDS 10. раньше триггер был черным ящиком. Когда наступало событие, отслеживаемое триггером, он запускался и что-то делал, а вам оставалось ждать, пока он завершит свои действия без возможности посмотреть, а что в этом триггере происходит. В IDS 10 введена возможность интроспекции триггера (trigger introspection), которая позволяет использовать API DataBlade и специальные функции для просмотра выполнения триггера. Например, можно просмотреть, какой уникальный идентификатор будет присвоен строке триггером, изменить значения переменных в триггере. Более подробно об этой возможности вы можете почитать в IBM Informix DataBlade API Programmer’s Guide. С помощью триггеров, UDR, хранимых процедур вы можете реализовать бизнес-логику не в приложении, а непосредственно в базе данных. Ограничения и индексы Ограничения и индексы используются для увеличения производительности запросов, отслеживания связи между элементами данных, задания допустимых значений для данных. Хотя индексы и ограничения поддерживаются Informix уже давно, но иногда возникает непонимание разницы между ними. Отчасти это вызвано тем, что в выводе утилиты dbschema ограничения могут быть представлены как индексы с забавными именами. Давайте подробнее рассмотрим разницу между индексами и ограничениями, а также использование каждого из них с точки зрения производительности и целостности системы. Логическая разница между ограничениями и индексами Один из частых вопросов – в чем разница между ограничением уникальности, первичным ключом и уникальным индексом (unique constraint, a primary key and a unique index). Ответ состоит из двух частей. С точки зрения логики разработки БД каждый из этих элементов играет отдельную роль. Во вторых, хотя все эти элементы построены на использовании индексов, но IDS по разному управляет индексами, ключами и ограничениями.

Давайте рассмотрим ограничения, ключи и индексы с точки зрения логики проектирования. Ограничения используются для обеспечения правил бизнес-логики в таблице. Они делятся на две группы. Во первых, ограничения могут использоваться для обеспечения уникальности строк. Например, имя заказчика должно быть уникально в таблице customer, а комбинация идентификатора пользователя и адреса доставки должна быть уникальна в таблице address. Такие ограничения реализуются с использованием индексов и называются ограничениями на основе индекса (index-based constraints). Второй тип ограничений – ограничения проверки (check constraints), которые используются для определения допустимых значений столбца. Например, сумма минимального заказа должна быть больше 50. такие ограничения реализуются не с помощью индексов, а с помощью правил, встроенных в схему таблицы. Первичные и внешние ключи являются еще одним типом ограничений. Ключи используются для определения ссылочной целостности между таблицами – часто используется также термин «главный-подчиненный». Ключи не позволяют вставить в подчиненную таблицу записи, для которых нет соответствия в главной таблице, а также препятствуют удалению из главной таблицы записей, для которых есть соответствующие записи в подчиненной таблице. На Рисунке 6.3 приведен пример такого проектирования для системы обработки заказов. Уникальный идентификатор покупателя – customer ID является первичным ключом и однозначно идентифицирует покупателя в системе. Строка в таблице order должна содержать действительный идентификатор покупателя (внешний ключ на таблицу customer) и уникальный номер заказа – первичный ключ. Таблица деталей заказа должна содержать действительный номер заказа (внешний ключ на таблицу order). В примере показано, что таблица может иметь и первичный ключ, и внешний ключ(и). Если вы удалите строку из одной из этих таблиц, не удалив соответствующие строки в других таблицах, то система будет работать неправильно. По умолчанию IDS не разрешает удалять из родительской таблицы строки, для которых есть соответствующие строки в дочерних таблицах. Если в команде создания внешнего ключа указать on delete cascade, то при удалении родительской строки автоматически будут удалены все подчиненные строки. Вы можете использовать эту возможность для уменьшения размера кода на SQL. Перед удалением родительской записи должны быть удалены все соответствующие ей дочерние записи. Если при удалении родительской строки невозможно удалить хотя бы одну дочернюю строку, то вся операция удаления родительской строки будет откачена, и ни одна строка не будет удалена. Индексы следует использовать только для повышения скорости выполнения запросов. Поэтому я считаю, что администратор БД никогда не должен создавать уникальные индексы на таблице. Если требуется уникальность, то ее нужно реализовать с помощью ограничения. Как я уже говорил выше, ограничения могут реализовываться на основе индексных структур. Оптимизатор может использовать эти структуры для ускорения выполнения запросов. Разница в управлении Informix по разному обрабатывает ограничения и индексы. Эта разница в обработке влияет на процесс выполнения SQL-запросов и, как следствие, на написание клиентских приложений. Ваша задача, как администратора IDS, помогать разработчикам учитывать эти особенности. Функциональные отличия ограничений от индексов таковы:

индексы обрабатываются (enforced) немедленно, вне зависимости от состояния транзакции и режима журналирования БД

ограничения обрабатываются (enforced) в конце транзакции

например, предположим, что у нас есть таблица заказчиков, в которой первичным ключом является столбец типа integer, начальное значение которого равно 1. вы хотите, чтобы 10 первых идентификаторов не использовались. Для решения этой задачи можно написать примерно такой запрос: begin work; lock table customer in exclusive mode; update customer set cust_id=(cust_id+10); Если для столбца cust_id задан уникальный индекс, то операция обновления завершится ошибкой при попытке обновления первой строки. Идентификатор cust_id первой строки должен быть изменен с 1 на 11, но значение 11 уже есть в индексных структурах, поэтому индекс препятствует изменению строки. Если для столбца cust_id задано ограничение уникальности (unique constraint), то транзакция будет завершена успешно, поскольку проверка уникальности будет производится после обновления всех строк. Если столбец cust_id является родительским по отношению к столбцам других таблиц, то дочерние таблицы должны быть обновлены раньше, чем родительская, для чего необходимо перевести ограничения в отложенный режим (setting constraints to deferred mode) . По умолчанию IDS обрабатывает ограничения в конце транзакции. Это не является проблемой для транзакций с одной операцией, наподобие приведенной выше. Ситуация слегка меняется, если в транзакции выполняется несколько операций. В этом случае ограничения обрабатываются после каждого выражения add, update,delete в транзакции. В случае наличия связи мастер-деталь, обработка ограничений после каждого выражения вызывает откат транзакции, поскольку данные не обновляются во всех необходимых таблицах. Решить эту проблему можно выполнив перед началом транзакции SQL-команду set constraints deferred. После выполнения этой команды ограничения будут обработаны после выполнения всех операторов в транзакции. Установка deferred-режима обработки ограничений влияет только на ту транзакцию, в которой сделана эта установка. После подтверждения или отката транзакции режим обработки соответствующих ограничений будет выставлен в immediate. Как создавать ограничения. Как уже упоминалось в начале, есть два типа ограничений – типа check и на основе индекса, ограничения каждого типа создаются по-разному. Ограничения типа check Эти ограничения используются для того, чтобы данные в одном или нескольких столбцах находились в заданном диапазоне значений. Такими диапазонами могут быть «больше, чем», «меньше, чем», «между». Ограничение check отличается от значения по умолчанию тем, что последнее применяется только в том случае, если во время вставки новой строки в таблицу для столбца не указано другое значение (отличное от значения по умолчанию). Создать ограничение этого типа можно несколькими путями. Например, так: create table division (division_no smallint, division_name char(16), check (division_no>5) constraint chk_div_divno); Можно изменить существующую таблицу и добавить в нее необходимое ограничение: alter table category add constraint check (category_no<25) constraint chk_cat_catno;

Обратите внимание, что в обеих примерах ограничение присвоено имя (chk_div_divno в первом примере и chk_cat_catno во втором). Давать имя ограничению не обязательно, но очень-очень желательно. Если вы не именуете ограничение или внешний ключ, то это имя им даст сервер БД. Нельзя сказать, что оно будет понятным для пользователя. Например, вот вывод схемы таблицы, при создании которой имя ограничения указано не было: create table “db_a”.division (division_no smallint, division_name char(20), check (division_no>5) constraint “db_a”._110_crom1); Использование имен также позволяет вам поддерживать стандарты именования для координации логической и физической модели БД. Ограничения на основе индекса (index-based constraints) Как следует из названия, эти ограничения создаются на основе некоторого индекса. Существует два типа ограничений на основе индекса – ключи для поддержания ссылочной целостности (первичные и внешние ключи referential integrity keys) и ограничения уникальности(unique constraints). Создавать ограничения на основе индекса рекомендуется в два шага – сначала создать соответствующий индекс, а затем - необходимое ограничение. Например, для создания ограничения ссылочной целостности между двумя таблицами можно использовать следующие команды: create unique index ix_divsn_1 on division (division_no) in danube_index_1; alter table division add constraint primary key (division_no) constraint pk_divsn_1; create index ix_strsls_2 on store_sales (division_no) in danube_index_2; alter table store_sales add constraint foreign key (division_no) references division constraint fk_strsls_1; Создать ограничение уникальности можно так: create unique index ix_cust_2 on customer(customer_name) in danube_index_3; alter table customer add constraint unique (customer_name) constraint uc_cust; При таком создании ограничений будет создан только один индекс (смотрите следующий раздел), хотя утилита dbschema для таблицы покажет оба объекта (индекс и ограничение). При работе с ограничениями, если вы хотите удалить его, никогда не удаляйте индекс, на основе которого создано ограничение, или информацию об этом ограничении из таблицы sysconstraints. Для удаления ограничения используйте только команду alter table, иначе придется разворачивать экземпляр из архива. Поверьте, я уже пробовал. Один раз.

Фрагментирование ограничений. Посмотрев на синтаксис создания ограничений, видно, что фрагментировать ограничения так, как фрагментируют индексы, нельзя. Ограничения на основе индекса должны создаваться в том же db-пространстве, что и сама таблица. В случае фрагментированной таблицы такое поведение ограничений негативно влияет на производительность. Для ограничений типа check вышеприведенное рассуждение не подходит, так как для таких ограничений индексы не создаются. Обойти эту проблему можно так. Индекс может быть превращен в ограничение, хотя обратное неверно. Это значит, что вы можете, например, создать уникальный индекс с некоторой схемой фрагментирования для таблицы. Затем, с помощью команды alter table, можно добавить ограничение уникальности по тем же столбцам, которые используются для создания индекса – существующий индекс будет использован для функционирования в качестве ограничения. Именно по этой причине для создания ограничений на основе индекса я использую двухшаговый процесс, описанный в предыдущем разделе. Имя ограничения, созданного с помощью этого метода, не будет совпадать с именем индекса. Вам необходимо самостоятельно задать имя ограничения или позволить экземпляру сделать это за вас. После обновления уникального индекса до ограничения или первичного ключа утилита dbaccess для таблицы покажет только исходный индекс. Однако dbschema покажет и индекс, и ограничение. Предупреждение из предыдущего раздела остается в силе – не удаляйте индекс, на котором построено ограничение, - сначала удалите ограничение, затем индекс. Такой метод фрагментирования ограничений работает для всех ограничений на основе индекса. Я настойчиво рекомендую его даже в том случае, когда таблицы или индексы не фрагментируются. Он позволяет быстро выделить определения индексов и ограничений, что может быть полезно при подготовке экспорта БД на другую систему. Ниже я более подробно расскажу об этом. Наполнение базы данных данными. Итак, вы создали базу данных, таблицы, индексы, ограничения, UDR, хранимые процедуры. Настало время залить в базу данные. Для выполнения этой задачи есть несколько утилит, каждая из которых имеет свои преимущества и недостатки. Некоторые из них, например, High Performance Loader, я могу описать только очень кратко, поэтому не забудьте проконсультироваться с документацией, которая идет в составе дистрибутива. Dbimport Первой мы рассмотрим программу dbimport, которая используется в паре с dbexport и предназначена для создания всего окружения БД, а затем наполнения таблиц базы данными, которые хранятся в плоских файлах. База данных создается как часть импорта, поэтому проблем с запрещением доступа пользователей к базе во время работы программы не возникает. На время импорта/экспорта база данных блокируется в эксклюзивном режиме и, как упоминалось выше, базу желательно создавать без журналирования. Если вывод dbexport делается на ленту, то командный файл можно сохранить не на ленту, а на диск. Вы можете отредактировать этот файл, но не меняйте порядок таблиц в файле, типы данных в таблице, не добавляйте/удаляйте столбцы, так как в противном случае возникнет ошибка при попытке загрузки файлов. В новых версиях IDS формат командного файла внесены некоторые усовершенствования для облегчения работы. Раньше сначала для таблицы выполнялись все DDL-выражения, а затем в нее заливались данные. Если для таблицы были заданы индексы и/или ограничения, то утилита создавала эти индексы и ограничения, а затем проводила загрузку данных в таблицу с индексом, что плохо влияло на производительность. В современных версиях создание индексов, ограничений и соответствующие команды alter table описаны в конце командного файла и выполняются после заливки данных в таблицы. Команды создания

процедур и триггеров также расположены в конце командного файла. В результате во время загрузки данных в таблицы не возникает дополнительной нагрузки на сервер. В реальном мире это очень хорошо, поскольку триггеры и хранимые процедуры обработали заливаемые данные в оригинальной БД. SQL-команда load Эта команда является наименее гибкой из всех обсуждаемых. Ее можно использовать для обработки малых и средних объемов данных в журналируемой БД или больших объемов данных в нежурналируемой БД или сырой таблице. эта команда читает плоский ASCII-файл с разделителями (delimited ASCII flat file) и загружает данные в столбцы целевой таблицы. В зависимости от наличия индексов для целевой таблицы загрузка данных может быть проведена очень быстро. Во время работы этой команды пользователи могут получить доступ к целевой таблице, если только при запуске команды load не была выставлена эксклюзивная блокировка таблицы. При использовании команды load может возникнуть целый букет проблем. В журналируемой БД эта команда выполняется как единая транзакция, как результат, возможно возникновение длинной транзакции. Для уменьшения количества необходимых блокировок вы можете установить эксклюзивную блокировку на таблицу, но в этом случае пользователи не смогут работать с такой таблицей. Еще одна проблема – отсутствие механизма обработки ошибок в плоском файле. Например, если в поле, которое должно быть загружено в столбец numeric, содержится алфавитный символ, то возникнет ошибка преобразования типов, и сервер откатит весь процесс. утилита ведет счет загруженных строк, что позволяет идентифицировать проблемную строку в плоском файле. Утилита dbload При работе с плоскими файлами обеспечивает большую гибкость, чем SQL-команда load или утилита dbimport. С помощью dbload можно выполнять следующие задачи:

загружать файлы с разделителями, без разделителей или фиксированной длины (delimited, fixed-length, non-delimited files)

загружать столбцы не загружать первые n строк таблицы записывать проблемные строки в файл-журнал одновременно с продолжением

загрузки других строк загружать простые ASCII-блобы для избежания возникновения длинной транзакции после загрузки каждых n строк

выполнять оператор commit work для столбца с ограничением not null заменять null другим значением.

Поведение утилиты определяется в командном файле. В этом файле содержится путь к загружаемому файлу, имя целевой таблицы, порядок столбцов в ней и инструкции по манипулированию данными. Вы также можете указать, сколько может случиться ошибок испорта прежде, чем процесс импорта будет отменен. Утилита не требует блокирования таблицы в эксклюзивном режиме. Если для таблицы созданы индексы, то скорость загрузки данных с помощью этой утилиты может существенно упасть. Утилита onload Это самая быстрая утилита загрузки данных. Используется совместно с утилитой onunload; читает данные таблиц с магнитной ленты и помещает таблицы и индексы в требуемые db-пространства. Вы можете задать параметры создания db-пространств,

переименовать индексы, изменить схему фрагментирования, определить db-пространства для хранения фрагментов индексов. Утилита onload выполняется в контексте единой транзакции и устанавливает эксклюзивную блокировку на таблицу. Вы не можете контролировать порядок заливки данных или изменять эти данные. Утилита во время экспорта сохраняет информацию о размерах экстентов таблиц, поэтому может использоваться для снижения количества экстентов в db-пространствах. Можно, например, с помощью onunload выгрузить таблицы на магнитную ленту, удалить таблицы из БД, а затем с помощью onload загрузить таблицы назад в базу. В результате выполнения таки операций все таблицы будут расположены в одном логическом экстенте (all the tables will occupy a single logival extent within the dbspaces). High-Performance Loader Я очень кратко расскажу об этой программе. Подробности смотрите в IBM Informix High-Performance Loader User’s Guide. High-Performance Loader (HPL) – самая быстрая программа загрузки/выгрузки данных IDS. С ее помощью вы можете извлечь или загрузить только часть данных, расположенных на диске или ленте, модифицировать данные в процессе загрузки/выгрузки, конвертировать форматы и т.д. вышеописанные утилиты работают одновременно только с одним файлом, а HPL может работать параллельно с несколькими файлами. HPL состоит из нескольких компонентов:

ipload - Linux/Unix-утилита, обеспечивает интерфейс для системы Х. С помощью ее интерфейса можно управлять всеми моментами создания и администрирования «проекта» HPL. В Windows также есть графическая утилита для этих целей. На момент сдачи книги в печать подобной программы для Mac OS X не было

onpload – исполняемый файл HPL. Осуществляет загрузку/выгрузку данных. Вы можете вызвать его непосредственно и передать необходимые параметры.

onpladm – консольная программа для управления HPL-проектом onpload – системная БД для хранения всех данных о проекте HPL. Создается

автоматически при первом вызове любой из описанных выше пользовательских программ.

plconfig – конфигурационный файл HPL, шаблон которого plconfig.std хранится в $INFORMIXDIR/etc.

При загрузке данных HPL может работать в режиме де-люкс или экспресс (deluxe or express mode). В режиме де-люкс все индексы, триггеры, ограничения активны, так словно пользователь работает с командой load. Выполнение больших заданий в этом режиме может привести к возникновению длинной транзакции, поэтому рекомендуется использовать точки подтверждения (commit points), когда блоки загруженных данных помечаются в экземпляре как подтвержденные, что позволяет своевременно освобождать логические журналы. Во время загрузки данных в этом режиме используемые таблицы полностью доступны для операций конечных пользователей. В экспресс-режиме таблица(ы) блокируются в эксклюзивном режиме, а все индексы и ограничения и другие объекты выключены. HPL переводит таблицу в сырой режим, а затем осуществляет загрузку данных. После завершения загрузки таблица переводится в стандартный режим. Экспресс-загрузка производится значительно быстрее, чем де-люкс, но после ее завершения необходимо выполнить архивирование затронутых db-пространств.

Рисунок 6.4. Организация проекта HPL На рисунке 6.4 показана организация проекта HPL. Для одного экземпляра может существовать множество проектов HPL, но каждый из них имеет свой набор дискретных заданий (загрузка, выгрузка, преобразование данных) с определениями всех параметров операции: путь к исходным файлам или лентам, SQL-команды преобразования данных и т.п. каждый элемент проекта задается отдельно, но эти элементы могут совместно использоваться несколькими заданиями или даже проектами. После определения всех необходимых элементов вы можете запустить задание, используя примерно такой синтаксис: onpload –p TPC –j TPCineitem –fl onpladm run job TPCineitem –p TCP –fl Графический интерфейс Server Studio позволяет управлять операциями HPL и выполнять их. Я настойчиво рекомендую его использовать. Это гораздо лучше, чем интерфейс ipload. Если HPL правильно сконфигурирован, то в экспресс-режиме можно достичь вставки в таблицу миллионов строк в минуту. Загрузка плоских файлов (flat files) с помощью 4GL или другого языка Если ни одна из вышеперечисленных программ вам не подходи – выход один: писать свою собственную. В Informix поддерживается «устаревший» язык IBM Informix 4GL – достаточно мощный, но ограниченный алфавитно-цифровым интерфейсом пользователя (character-based user interface). Это не является недостатком: приложения, управляемые с клавиатуры, гораздо быстрее, чем их графические аналоги. По многим причинам загрузка данных с помощью приложений 4GL не должна включаться в список рассмотренных нами программ. Informix 4GL не был разработан для создания программ загрузки данных, хотя с его помощью можно создать очень устойчивые к ошибкам приложения. Я упоминаю программы на этом языке потому, что они до сих пор активно используются. Во-вторых хочу показать вам маленькую часть функциональности 4GL. В каталоге $INFORMIXDIR/demoa/4glbe можно посмотреть

демонстрационные примеры. Один из них посвящен чтению данных из плоских ASCII-файлов. Команда fglgets() в качестве параметра принимает имя файла, открывает его и возвращает первую строку в файле; если файл уже открыт, то команда возвращает следующую строку файла. Команда fglgetret проверяет код возврата С-функции pop, которая читает строку из файла. Давайте рассмотрим часть кода (Листинг 6.9) и я приведу необходимые комментарии. database my_test_db main define fname varchar(30) define in_str varchar(255) define nrecs integer ##обратите внимание, что в примере обработка ошибок не производится prompt “Please enter pathed file name to load: ” for fname let fname=fname clipped ##открываем файл и получаем первую строку call fglgets(fname) returning in_str ##проверяем статус open и pop while fglgetret()=0 let nrecs=nrecs+1 if nrecs mod 100=0 then display “Loading row: ”, nrecs using “###,###” at 8,2 end if call process_row(in_str) ##продолжаем получение строк до достижения конца файла call fglgets(fname) returning in_str end while ## fglgetret=0 end main Листинг 6.9 простое приложение 4 GL для загрузки данных из файла Некоторые замечания по использованию 4GL для загрузки плоских файлов:

для использования fglgets() и fglgetret необходимо скомпилировать в объектную форму файл fglgets.c и включить путь к объектному файлу в файлы сборки (makefiles).

Функция fglgets() открывает файл, но не закрывает его Функция fglgets() позволяет двигаться по файлу только «вперед», вы не можете,

как в С, переустановить указатель на позицию в файле. Можно прочитать строку с максимальным размером до 256 байт

Можно обработать 8 файлов, затем необходимо перезапускать приложение. Это поведение контролируется параметром MAXOPEN файла fglgets.c. При необходимости вы можете изменить этот предел.

Каждый раз при вызове fglgets() с новым имененм файла счетчик открытых файлов увеличивается на единицу, даже если файл не существует или его невозможно открыть.

Если количество открытых файл превышает MAXOPEN, приложению сообщение об ошибке не возвращается. Вместо этого данные просто не возвращаются. С точки зрения приложения это выглядит так, будто файл пуст. Поэтому необходимо или увеличить значение MAXOPEN или считать, сколько раз вы пытались открыть файл, чтобы прекратить попытки сделать это если достигнуто количество попыток MAXOPEN

Помещение вызова fglgets() в вызываемую функцию не влияет на счетчик MAXOPEN. Этот счетчик работате на уровне приложения, а не на уровне модуля

Конкурентные сессии и уровни изоляции После заполнения БД данными важной задачей становится обеспечение и защита многопользовательского доступа к базе. Защита реализуется путем использования блокировок, а обеспечение во многом зависит от приложения (как приложение обрабатывает доступ к заблокированным данным). На оба эти аспекта существенно влияет режим журналирования базы данных. Термин конкурентность (concurrency) относится к обеспечению одновременного доступа к данным многих пользователей. Термин уровень изоляции (isolation level) относится к влиянию на выполнение запроса других запросов к тем же данным (refer to the impact a database action request should be allowed to have on other concurrent action requests). Эти два аспекта многопользовательского доступа тесно связаны между собой. Очень жесткий уровень изоляции существенно повышает количество конкурентных обращений к данным. Типы и режимы блокировок Чтобы понять вопросы конкурентного доступа к данным и уровней изоляции необходимо понимать, как Informix устанавливает блокировки и управляет блокированием данных. Блокировка может быть установлена и на такую маленькую часть данных, как значение ключа, и на такую большую, как целая база данных. В таблице 6.2 приведено описание четырех типов блокировок IDS

Таблица 6.2 типы блокировок Informix Dynamic Server Тип блокировки

Описание

Эксклюзивная (exclusive)

Доступ других пользователей к заблокированным данным запрещен, разрешен доступ только пользователю, установившему блокировку. На уровне строк блокировка устанавливается SQL-операциями update или delete. На уровне таблицы или базы данных – командами пользователя

Совместная (share) Устанавливается читающими транзакциями для гарантирования того, что элементы данных записаны на диск (to make sure data elements have been written to disk). Можно использовать эту блокировку для запрещения удаления или изменения прочитанных данных пока они нужны читающей транзакции

Тип блокировки

Описание

Обновляемая или повышаемая(upgradeable or promotable)

Разделяемая блокировка, которая может быть при необходимости повышена до эксклюзивной. Блокировки этого типа используются курсорами обновления (update cursors).

Байтовая (byte) Устанавливается на строки если запрос воздействует на столбцы типа varchar

С помощью SQL-запросов пользователи могут устанавливать разделяемые и эксклюзивные блокировки на таблицы и базы данных. Informix Dynamic Server самостоятельно устанавливает эксклюзивную блокировку на таблицу при выполнении DDL-операций, таких как alter, drop table, rename, rename column. После выполнения операции блокировка снимается, пользователю нет необходимости отдельно использовать выражение lock. Блокировки, инициированные пользователем, сохраняются на протяжении выполнения транзакции в жкрналируемой БД, в нежурналируемой БД такие блокировки необходимо удалять самостоятельно. Уровни изоляции. Уровни изоляции определяют то, как сервер обрабатывает запросы на чтение. В таблице 6.3. описаны 4 уровня изоляции, применяемые Informix Dynamic Server

Таблица 6.3. Уровни изоляции Informix Dynamic Server

Уровень изоляции Описание

repeatable read Самый жесткий уровень. Устанавливает совместную блокировку (share lock) на все читаемые строки до завершения транзакции. Необходимо помнить, что разделяемые блокировки ставятся только если чтение выполняется в явной транзакции. Установка уровня изоляции repeatable read, а затем выполнение select не обеспечивает той защиты данных, которая обеспечивается этим уровнем изоляции. Если не запущена явная транзакция (begin work…commit work), другие потоки могут изменять выбираемые строки. Этот уровень изоляции применяется по умолчанию в ANSI –совместимых БД

cursor stability Устанавливает разделяемые блокировки на строки, читаемые курсором. Важное отличие от repeatable read – как только курсор обращается к следующей строке данных, блокировка с предыдущей строки снимается. Разделяемая блокировка ставится только в том случае, когда курсор находится внутри явной транзакции. Этот уровень изоляции мало эффективен в ad-hoc сессиях, наподобие сессий dbaccess и подобных утилит. Хорошо подходит для курсоров, объявленных в клиентских приложениях., написанных на стандартных языках типа Java, C

committed read Уровень изоляции по умолчанию для журналируемых БД, за исключением ANSI-совместимых БД. Этот уровень изоляции гарантирует чтение только подтвержденных строк. Перед возвращением строки клиенту экземпляр проверяет, можно ли установить на строку разделяемую блокировку. Строка не

блокируется, поэтому по скорости committed read сопоставим с dirty read. Этот уровень изоляции не запрещает модификацию данных другими потоками, даже если установлен внутри явной транзакции. При применении read committed не возвращаются строки, заблокированные для обновления, вставки, удаления, что может негативно повлиять на работу, если приложение, выполняющее обновление строк, не завершает эту работу в разумный срок времени. Для борьбы с этой напастью в IDS 11 введен оператор last committed

dirty read Самый мягкий уровень изоляции. Приложению возвращаются все строки, подтвержденные и нет (committed or not), в том числе строки, которые могут быть изменены операцией update и вставленные, но пока не подтвержденные строки. Полученные строки могут быть удалены из-за отката транзакции или действий другого пользователя. В IDS 11 для минимизации этого риска введен уровень изоляции last committed.

Любой уровень изоляции устанавливается с помощью команды set isolation. В зависимости от требований к целостности считываемых данных в приложении вы можете использовать разные уровни изоляции. Когда вы считываете неизменяемые данные, можно использовать уровень изоляции dirty read. Если необходимо, чтобы считанные данные были неизменяемы, используйте уровни repeatable read и cursor stability. Установка уровня изоляции для сессии может запретить другим сессиям доступ к этим же данным. Например, сессия А начинается транзакцию по обновлению одной или нескольких строк в таблице. Конкурирующая сессия Б пытается прочитать одну из этих строк. Поскольку база данных журналируемая, обе сессии используют режим изоляции read committed, и сессия Б получает с сервера ошибку SQL –107. Перед IDS 11 повсеместной практикой было использование в приложениях уровня изоляции dirty read, в надежде на то, что когда вторая сессия будет готова делать изменения, первая сессия получит требуемые данные. Такой подход порождает нехорошую проблему – пусть сессия Б получила некие промежуточные данные и на их основе проводит вычисления, в этот момент сессия А откатывает транзакцию и возвращает данные с исходное состояние, в результате сессия Б работает с неправильными данными. Классическая проблема – взаимоблокировки (deadlock). Предположим сессия А заблокировала для проведения обновления строку 2, а затем пытается заблокировать строку 450. Конкурирующая сессия Б заблокировала для обновления строку 450 и пытается заблокировать строку 2. В результате обе сессии не могут установить необходимые им блокировки, зависают до достижения времени deadlock timeout, и обе транзакции откатываются. В IDS 11 введен модификатор уровня изоляции read committed, который может быть использован с уровнями изоляции dirty read и committed read. Его можно установить через переменную окружения, команду SQL или файл $ONCONFIG для всех сессий, этот новый модификатор приказывает экземпляру вернуть последнее подтвержденное значение (last committed value) заблокированной строки вызывающей сессии, и в результате сессия может продолжить работу. Поэтому в первом примере сессия Б получит подтвержденную версию строки, которую сессия А заблокировала для потенциального изменения. В примере о взаимоблокировке обе сессии получат исходную подтвержденную строку, которая им необходима, и смогут продолжить работу. Некоторые интересные SQL-запросы В каждом выпуске Informix Dynamic Server IBM внедряет новую функциональность SQL. Полное описание нововведений находится в документах The IBM Informix Guide to

SQL:Syntax и IBM Informix Dynamic Server Administrator’s Guide. Здесь мы кратко рассмотрим некоторые новые возможности. Другие изменения, например, изменения в команде update statistics, рассмотрены в соответствующих частях этой книги или в “Administering Informix Dynamic Server, Advanced Topics “. Нарушения и диагностика, активация и фильтрация ограничений и индексов (violations and diagnostics, constraint and index enabling and filtering) Есть два пути обработки ошибок обновления или вставки строк в таблицу с уникальными индексами или ограничениями на основе индекса. Первый – обрабатывать в вашем приложении sqlca.sqlerrd коды, определять тип ошибки, и решать, как ее исправить. Чаще всего проблемная строка записывается в некоторую промежуточную таблицу для последующей ручной обработки. Вторая возможность – переложить эту работу на сервер, уменьшив количество кода обработки ошибок в клиентском приложении. Вы можете создать таблицы нарушения и диагностики (violation and diagnostic tables) для интересующих вас таблиц, а затем активизировать возможности обработки ошибок уникальных индексов и ограничений на основе индекса. Выполнение команды SQL start violations table для некоторой таблицы приводит к созданию двух таблиц, фрагментированных так же, как и основная. В одной таблице содержится информация о нарушении (violation information), во второй – диагностическая информация (diagnostic information). Вы можете самостоятельно дать имена этим таблицам, по умолчанию эти таблицы именуются так же, как и целевая, но с дополнительным суффиксом _vio и _dia. Вы также можете задать количество строк, которые могут быть записаны в эту таблицу. Таблица нарушений (violation table) имеет такую же схему, как и основная таблица, плюс несколько дополнительных столбцов. В этих столбцах содержится счетчик, аббревиатура операции, приведшей к ошибке, и идентификатор пользователя, выполнявшего операцию, завершившуюся ошибкой. В диагностической таблице (diagnostic table) содержится числовой столбец, ссылающийся на строку в таблице нарушений. Эти столбцы не связаны отношением первичный-вторичный ключ. В диагностической таблице есть столбец, в котором указан тип ошибки (нарушение индекса или ограничения), имя индекса или ограничения и владелец индекса или ограничения. Следующий шаг – активировать режим объектов для ограничений и индексов. Термин режим объекта (object mode) относится к режиму функционирования объекта. В данном случае под термином «объекты» я понимаю только ограничения и индексы. Вы можете установить режим для всех индексов и ограничений таблицы или выборочно для некоторых. В таблице 6.4 описаны три режима объектов

Таблица 6.4. режимы объектов для ограничений и индексов

режим описание

Включено (enabled)

Процесс останавливается, если операция update/delete/insert завершилась с ошибкой. Режим по умолчанию для индексов и ограничений на основе индекса

Отключено (disabled)

Экземпляр полагает, что ограничения и индексы отключены

Фильтрация (filtering)

Экземпляр работает так же, как и в случае режима «enabled», т.е. в таблицу записываются только строки, удовлетворяющие необходимым условиям. Ошибочные строки записываются в таблицу ошибок (violation table), а диагностическая информация – в таблицу диагностики (diagnostic table)

Вы можете определить, что будет возвращать экземпляр клиентскому приложению, если индекс или ограничение находятся в режиме фильтрации (filtering mode) и операция завершилась ошибкой. Эта возможность носит название «установка опции ошибок» (setting the error option). Экземпляр может вернуть приложению код ошибки (with error), а может и не возвращать (without error). Рассмотрим пример этого функционала на примере таблицы orders с ограничением уникальности на столбец order_num: start violations table for orders; set constraints for orders filtering without error; Таблицы ошибок и диагностики, создаваемые этими командами, не будут удалены до тех пор, пока режим объекта не будет изменен с filtering на enabled/disabled и не будет выполнена команда stop violations. После этого вы можете удалить таблицы ошибок и диагностики также, как и обычные таблицы. Должен сказать, что дублирующиеся индексы и триггеры (duplicate indexes and triggers) допустимы только в режимах enabled/disabled и недопустимы в filtering режиме. Роли по умолчанию С каждой версией Informix в него добавляются новые возможности по обеспечению защиты баз данных и экземпляров. Роли всегда использовались для ограничения доступа пользователей к данным, но раньше необходимо было руками назначать каждому пользователю роль, что приводило часто к различным ошибкам. В последних версиях Informix добавлена возможность назначать пользователю роль по умолчанию. Реализуется это так: grant role it_dep to jerry; grant role hr to susan; grant default role payroll to marilyn; Функции-итераторы (iterator functions) и производные таблицы в выражении from В нескольких последних выпусках IDS были добавлены расширения по использованию производных таблиц в выражении from. Первое расширение – возможность использования функции-итератора. IBM Informix DataBlade API Programmer’s Guide (страница 15-4) трактует функцию-итератор как «определенная пользователем функция, которая вызывается несколько раз, возвращает данные, а сервер БД собирает эти данные вместе в активном наборе (active set)». Примером такой функции может быть вычисление последовательности Фибоначчи: F(n)=F(n-1)+F(n-2)+F(n-3)…., n>1 IDS трактует набор значений, возвращаемых такой функцией, как таблицу, значения которой могут быть использованы в секции where запроса. IDS 11 обеспечивает полную поддержку производных таблиц (derived tables) или использование выражения select в секции from. В Листинге 6.10 приведены примеры: select sum(virt_col1) as sum_vc1,vc2 from(select col_1,col_2 from tab_1) as virtual_tab(virt_col1,virt_col_2) group by vc2;

select * from ((select col1, col2 from tab_3) as virt_tab_3 (vcol_31,vcol_32) left outer join ((select col1,col2 from tab_1) as virt_tab_1(vcol1,vcol2) left outer join (select col1,col2 from tab_2) as virt_tab_2 (vcol3, vclo4) on virt_tab_1.vcol1=virt_tab_2.vcol3) on virt_tab_3.vcol_31= virt_tab_2.vcol3); select * from table(fib_function(5)) as virt_t(a),tab1 t where virt_t.a=t.x Листинг 6.10 Создание производных таблиц в IDS 11 С помощью этого функционала вы можете писать очень мощные запросы без использования временных таблиц. Функции работы с датами и временем (date and date-time functions) Кроме использования функций работы с датой и временем в схемах фрагментирования, в IDS 11 добавлены некоторые новые функции обработки даты и времени. Функция round() возвращает округленное до желаемой точности значение типа date или datetime, переданное в функцию. Аргумент точности может быть ближайшим годом, месяцем, днем месяца, днем недели, часом или минутой. Например, пусть в строке таблицы содержится значение 2008-02-26 14:30:1213455 (поле типа datetime). Тогда: select round(col_dt, ’YEAR’) from mytab; (результат) 2008-01-01 00:00 select round(col_dt, ’DD’) from mytab; (результат) 2008-02-27 00:00 select round(col_dt, ’HH’) from mytab; (результат) 2008-02-26 15:00 select round(col_dt, ’MI’) from mytab; (результат) 2008-02-26 14:30 Функция trunc() возвращает дату, усеченную до необходимо точности (тип данных date, datetime). Параметры функции идентичны round(). Для вышеприведенного значения типа datetime функция возвращает такие результаты: select trunc(col_dt,’YEAR’) from mytab (результат) 2008-01-01 00:00 select trunc(col_dt,’YEAR’)::date form mytab (результат) 01/01/2008

select trunc(col_dt,’MONTH’) from mytab (результат) 2008-02-01 00:00 select trunc(col_dt,’DD’) from mytab (результат) 2008-02-26 00:00 Функция add_months() на входе получает значение типа date/datetime и целое, представляющее количество месяцев, которое необходимо прибавить к дате, и возвращает модифицированную дату. Функция last_day() возвращает последнюю дату в месяце, который передается в составе типа данных date/datetime в функцию. Функция next_day() вычисляет следующий требуемый день для переменной типа date/datetime, переданной в функцию. День недели указывается с помощью трехбуквенной аббревиатуры (SUN, MON и т.д.). Например, select next_day(col_dt, ’MON’) from mytab; (результат) 2008-03-03 Функция months_between() вычисляет разницу в месяцах между двумя переменными типа date/datetime и возвращает значение типа decimal. Например, пусть мы хотим вычислить разницу в месяцах между 1 ноября и 7 декабря. select months_between(date_1,date_2) from mytab; (результат) 1.2009453 Значения в функцию можно передавать в любом порядке. Если первая дата позже второй, то возвращается положительное число, иначе – отрицательное. Манипуляции со строками В IDS 11 добавлены новые возможности манипулирования строками. Например, можно удалить все символы слева/справа в строке на основе некоторой подстроки (удалить слева/справа некоторую подстроку). Пусть например, в строке таблицы mytab хранится такой текст: “If the first date passed is the later of the two, the returned value will be a positive number”, тогда: select ltrim(strngcol, ”If the first date “) from mytab; (результат) “passed is the later of the two, the returned value will be a positive number” Функция rtrim() выполняет такую же операцию, но удаляет символы справа. Последовательности (sequences) В Informix этот тип данных шел давно. Другие сервера уже давно им обзавелись, и вот он появился в Informix Объект sequence во многом похож на типы данных serial, serial8: он генерирует одно или больше значений, в зависимости от того, как вы вызываете объект. Но, в отличие от serial, serial8, sequence является объектом уровня базы данных, а не таблицы. Это позволяет использовать sequence для генерации глобально-уникальных идентификаторов (GUID). Объект sequenceсостоит из двух частей – самой sequence, конфигурирование которой показано ниже, и опциональной таблицы. Создать последовательность можно с помощью SQL-команды create sequence, которая имеет несколько дополнительных флагов. Вы можете задать стартовое значение последовательности, генерировать значения по возрастающей или убывающей, установить максимальное и минимальное значение,

указать шаг приращения, пропустить n значений между возвращаемыми числами. Можно указать, возвращает ли последовательность уникальные номера или работает в цикле между минимальным и максимальным значением. После создания объекта sequence к нему можно прямо обратиться и получить новое или текущее значение. В Листинге 6.11 показан новый функционал IDS 11 – таблица sysdual в БД sysmaster. create sequence my_seq_1 increment by 2 start with 2 nocycle; select my_seq_1.nextval from sysmaster@mproduction:sysdual; nextval 2 select my_seq_1.nextval from sysmaster@mproduction:sysdual; nextval 4 select my_seq_1.currval from sysmaster@mproduction:sysdual; currval 4 select my_seq_1.nextval from sysmaster@mproduction:sysdual; nextval 6 select my_seq_1.currval from sysmaster@mproduction:sysdual; currwal 6 Листинг 6.11 Создание и использование объектов sequence в IDS 11 Последовательности, в зависимости от количества строк в опциональной таблице доступа, могут генерировать при каждом обращении более одного значения, поэтому будьте аккуратны при использовании не таблицы sysdual, а другой. Убедитесь, что в таблице доступа находится столько строк, сколько значений вы хотите получить от одного вызова объекта sequence. В Листинге 6.12 приведена иллюстрация вышеописанной особенности. create sequence my_seq_2 start with 1 nocycle; create table yoyo (col1 char(1)); insert into yoyo values (“a”); insert into yoyo values (“b”); insert into yoyo values (“c”); insert into yoyo values (“d”); select my_seq_2.nextval from yoyo; nextval 5 6 7 8 select my_seq_2.currval from yoyo; currval 5 6 7 8

create table yoyo_2 (col1 char(1)); insert into yoyo_2 values (“z”); select my_seq_2.nextval from yoyo_2; nextval 9 selectmy_seq_2.nextval from yoyo; nextval 10 11 12 13 Листинг 6.12 Функционал объекта sequence в зависимости от количества строк в таблице доступа Как видите, если в таблице доступа 4 строки, то объект sequence (my_seq_2) возвращает четыре значения. но когда я связал с объектом таблицу с одной строкой (yoyo_2), было возвращено только одно значение. Вы можете использовать последовательности в выражениях DML, как показано ниже: insert into my_table values (my_seq_2.nextval,….); insert into my_other_table values(my_seq_1.nextval,my_seq_2.currval,my_seq_3.nextval,…) Триггеры на представления В большинстве случаев разработчики рассматривают представления как объекты только для чтения, задача которых – скрывать таблицы от пользователей или упростить написание SQL-запросов. Представления могут быть и обновляемыми. Изначально это касалось только представлений, построенных на одной таблице, но в последних версиях стало возможным выполнять операции insert/delete/update для представлений на основе нескольких таблиц. Новые возможности доступны на основе триггеров instead of для представлений. Для этих триггеров существует несколько правил:

В зависимости от обрабатываемого действия, вы можете использовать referencing new (insert), referencing old (delete) или оба эти выражения, но в триггере не можете использовать блоки before и after

В триггере требуется использовать for each row Не поддерживаются операторы select, when

В Листинге 6.13 приведен пример триггера instead of для операции вставки create trigger my_ins_trig_on_view instead of insert on my_view referencing new as new for each row (exexcute procedure ins_basetables(new.value1, new.value2,new.value3));

create procedure ins_basetables (var1 int, var2 int, var3 int) insert into table_1 values(var1); insert into table_2 values (var2,var3); insert into table_3 values (var1, current); end procedure; Листинг 6.13 Выполнение триггераinstead of при вставке в многотабличное представление. Order-by не в списке select (Order-by not in Select List) Эта возможность не из серии «надо немедленно использовать» и «как я этого ждал». Она решает проблему, которая лично меня очень раздражает. В ранние времена, если я хотел использовать sort или order by по столбцу(ам), то был обязан включать этот столбец/столбцы в select, даже если в клиентском приложении они абсолютно не нужны. На данный момент нижеприведенный синтаксис считается абсолютно правильным: select a.col1, b.col3, a.col4 from my_table a, my_other_table b where a.col1=b.col9 order by b.col7 при выполнении такого запроса оптимизатор выберет и b.col7, чтобы выполнить на его основе order by, но в результат запроса b.col7 не попадет Утилита dbschema Позволяет просматривать и сохранять «схему» БД, или DDL-операторы, которые используются для создания объектов в БД. Также позволяет просматривать информацию, используемую оптимизатором при построении планов(часто упоминается как распределении данных или «data distribution»). У утилиты много флагов управления, но один из них я считаю обязательным к использованию: -ss (строчная буква ). Это флаг «server-specific». Ниже приведен пример использования этого флага: dbschema -d my_db {TABLE “informix”.my_stock row size=51 number of columns=8 index size=18} create table “informix”.my_stock ( stock_num smallint, manu_code char(3), description char(15), unit_price money(6,2), unit char(4), unit_descry char(15), ifx_insert_checksum integer default null, ifx_row_version integer default 1, primary key(stock_num, manu_code) ); revoke all on “informix”.my_stock from “public” as “informix”; Листинг 6.14. Пример вывода утилиты dbschema без флага –ss

dbschema -d my_db -ss {TABLE “informix”.my_stock row size=51 number of columns=8 index size=18} create table “informix”.my_stock ( stock_num smallint, manu_code char(3), description char(15), unit_price money(6,2), unit char(4), unit_descry char(15), ifx_insert_checksum integer default null, ifx_row_version integer default 1, primary key(stock_num, manu_code) ); first extent 5600 next size 560 fragment by expression (stock_num>6000) in data_3, (stock_num>4000) in data_2, (stock_num>2000) in data_1, (stock_num<=6000) in my_old_data; revoke all on “informix”.my_stock from “public” as “informix” Листинг 6.14 (часть 2). Пример вывода утилиты dbschema с флагом –ss Флаг –ss показывает размеры экстентов таблицы, схемы фрагментирования данных и индексов (если эти схемы существуют). Этот же флаг можно использовать при экспроте базы с помощью dbexport. Я также часто пользуюсь флагом, который выгружает схему только одной таблицы или представления. Просто при вызове команды добавьте флаг –t имя_таблицы: dbschema –d test1 –t store_sales –ss Без флага –t утилита выгружает схему всех таблиц и процедур базы, указанной после флага –d. Флаг –hd показывает распределение данных ( «data distribution»), которое используется оптимизатором при построении плана запроса. Более подробно о распределении данных мы поговорим во второй книге. В Таблице 6.5 приведены часто используемые флаги утилиты dbschema

Таблица 6.5. Часто используемые флаги утилиты dbschema Флаг

Описание

-d имя_базы Имя базы данных активного экземпляра, для которой используется команда

-t имя_таблицы Имя талицы или представления, схему которых необходимо получить. Если не указывать флаг, то осуществляется выгрузка схемы для всех таблиц и представлений БД

-ss Генерирует все команды SQL, необходимые для полного воссоздания структуры таблицы. Включает вывод информации об экстентах и схеме фрагментирования (если есть)

-р идентификатор_аккаунта

Показывает информацию о полномочиях (проще говоря grant-команды). Если указать идентификатор аккаунта, будет возвращена информация только о полномочиях данного аккаунта или роли

-f имя_функции Выводит информацию о определенной пользователем функции (UDR) или процедуре. Если не указывать имя функции, будут возвращены данные о всех процедурах и функциях. В БД

-r имя_роли Возвращает информацию об определенной роли в БД. Без указания имени роли, возвращает данные обо всех ролях в БД.

-u Выводит DDL определенных пользователем типов данных. Для вывода всех типов используется флаг all, для вывода дерева наследования определенного типа используется дополнительный флаг i имя_типа

-si Исключает из вывода схему фрагментирования индексов для таблиц без фрагментирования

Заключение. В этой части мы рассмотрели разнообразные вопросы, касающиеся администрирования баз данных. Сейчас вы должны уметь создавать базы данных, таблицы и индексы, строить схемы фрагментирования таблиц и индексов, фрагментировать таблицы и индексы по алгоритму round-robin и по выражению, ориентироваться в концепции транзакций и уровней изоляции. При администрировании баз данных учитывайте следующие моменты:

Во многих случаях администрировать сервер проще из командной строки, чем с помощью графических средств. Для удаленного администрирования сервера необходимо знать различные административные SQL-запросы.

Алгоритм round-robin наследует все недостатки RAID0, но позволяет ускорить доступ к таблице, если она расположена в одном db-пространстве. Индексы, создаваемые для таблицы, фрагментированной по round-robin, нельзя создавать как корезидентные (co-resident), эти индексы необходимо создавать в другом db-пространстве.

Если используется фрагментирование по выражению, самое ограничивающее условие должно быть записано первым. Выражения фрагментирования желательно делать простыми, поскольку они вычисляются всякий раз, когда осуществляется вставка или обновление строки. По возможности избегайте использования в выражениях фрагментирования столбцов serial, date, datetime.

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

Запускайте утилиту dbschema с ключом –ss всякий раз, когда серьезно изменили таблицу или индекс (в большинстве случаев изменяется схема фрагментирования) – это позволит вам убедиться, что схема является «правильной».

Не делайте многократных изменений структуры таблицы, поскольку это негативно влияет на производительность.

В этом разделе мы обсудили многие задачи, которые выполняет администратор баз данных. Следующая часть посвящена одной из самых важных задач администрирования – восстановлению системы в случае сбоя: мы поговорим о архивировании и восстановлении баз данных.

Часть 7 Архивирование и восстановление

В этой части:

Методики выполнения архивирования Архивирование логических журналов Опции ленточного устройства Как работает процесс архивирования Использование ISM и набора утилит ON-Bar

В любой работе есть задачи, которые необходимо выполнять регулярно, какими бы скучными и неинтересными они бы не были. В одних случаях эта задача является частью большого процесса, в других – важна сама по себе, и сбой ее выполнения может привести к печальным последствиям. Задачи архивирования (бэкапа) и восстановления относится именно ко второй категории. Это скучная работа, очень немногие посвятили себя обслуживанию процесса бэкапа экземпляров IDS.Но когда приходит время восстановления, нет ничего важнее наличия актуального и целостного архива данных. В этой части мы поговорим именно о бэкапе и восстановлении. Я расскажу, как выполняется архивирование, когда экземпляр находится в он-лайне, какие типы устройств хранения поддерживает Informix, как выполнять архивирование с помощью утилиты ontape, как работать с пакетом ON-Bar. Мы рассмотрим конфигурирование и использование Informix Storage Manager (ISM). После прочтения раздела вы будете готовы реализовать процесс архивирования вашего окружения. Перед началом рассмотрения я сделаю одно уточнение – я полагаю, что вы осуществляете бэкап экземпляра или логических журналов на магнитную ленту. Это может быть не так в вашем случае, особенно учитывая недавние улучшения в работе ontape при архивировании данных на диск. Я буду использовать фразу «на ленту» для обозначения архивирования данных на диск или магнитную ленту. На практике рекомендуется иметь набор бэкапов на ленте и хранить их в другом месте для восстановления системы после катастрофических сбоев. Стратегии резервирования данных. Когда-нибудь вам будет необходимо выполнить полное или частичное восстановление данных. Ошибка пользователя или катастрофический сбой железа – неважно, но невозможность восстановить систему будет, возможно, стоить вам работы. Поэтому вам нужно иметь и стратегию резервирования данных, и оборудование для реализации этой стратегии. Informix Dynamic Server включает в себя два инструмента резервирования данных – утилиту ontape и набор программ ON-Bar. Первый из них самодостаточный, второй позволяет подключать сторонние системы управления лентами для резервирования и восстановления экземпляров или определенных db-пространств. Частью Informix Dynamic Serverтакже является система управления лентами Informix Storage Manager(ISM), которая позволяет использовать ON-Bar без необходимости устанавливать сторонние системы управления лентами, правда функционал этой системы несколько ограничен. Набор программ ON-Bar и связанные с ним системы управления могут существенно облегчить проектирование и реализацию системы резервирования и восстановления данных. На разработку стратегии бэкапов влияют многие факторы. Ниже приведены основные:

Какова допустимая гранулярность восстановления Какой объем данных резервируется и восстанавливается

Насколько легко могут быть восстановлены потерянные данные Сколько времени длится резервирование экземпляра, если резервирование

запускается во время обслуживания экземпляра Какова допустимая длительность времени восстановления Какие физические устройства резервирования данных доступны Сколько времени должны хранится бэкапы экземпляра

Эти факторы по отдельности и во взаимосвязи друг с другом будут определять, будете ли вы использовать «целостный» подход к резервированию (“whole-istic approach”), т.е. архивирование всего экземпляра или фокусный подход на уровне отдельных db-пространств или комбинацию того и другого. Большинство виденных мной систем использовали целостный подход, но иногда более полезным представляется фокусный. Он позволяет достичь большей гранулярности восстановления критически важных таблиц, но более сложен в реализации и управлении. Фокусный подход IDS не поддерживает восстановление отдельных таблиц с помощью ontape или ON-Bar (этого можно достичь с помощью схем фрагментирования или программы archecker), поэтому вам необходимо самостоятельно разрабатывать процедуры резервирования отдельных таблиц. Это резервирование может сопровождаться бэкапами всего экземпляра. Процедура резервирования таблиц обычно включает в себя выгрузку таблицы в каком-либо виде. В зависимости от размера таблицы и необходимости доступа к ней во время резервирования, вы можете осуществлять выгрузку с помощью SQL-команды unload или с помощью High-Performance Loader (HPL). Ключевые таблицы могут выгружаться и архивироваться несколько раз в день или неделю. Вы можете также использовать этот подход для передачи копий таблиц на другие сервера, если репликация данных по каким-то причинам невозможна. Другой вариант этого метода резервирования, особенно актуальный для OLAP-систем, это резервирование только данных, а не базы целиком (to back up the load data rather than the database itself). Эта методика полезна, если множество агрегирующих таблиц может быть загружено из одного файла. Но не забывайте выполнять и полное резервирование OLAP-базы. Этим вы снизите количество файлов, необходимых для потенциального восстановления базы данных/экземпляра. эти файлы могут быть перемещены в стороннее хранилище. С помощью набора ON-Bar возможно выполнять резервирование группы из одного или нескольких db-пространств. Если вы следуете рекомендациям размещать каждую критическую таблицу в отдельном db-пространстве, то такое резервирование будет полной функциональной копией резервирования отдельных таблиц. Ниже я расскажу, что восстановление архивов такого типа повлияет не только на таблицы в db-пространствах. С помощью возможностей программы archecker возможно провести восстановление отдельной таблицы или даже ее части. Как вы увидите, сначала данные восстанавливаются в новую таблицу, а затем переносятся в целевую таблицу. С помощью этого метода вы сможете скомбинировать фокусный и целостный подход к резервированию данных. Целостный подход

Это самый распространенный подход к резервированию данных. С помощью ontape или ON-Bar вы можете выполнить резервирование всего экземпляра или его части на ленту. При использовании ontape вы должны выполнять бэкап всего экземпляра, но при необходимости можете провести восстановление на уровне db-пространств. Большинство операций восстановления db-пространств могут быть проведены, когда экземпляр находится он-лайн.

С помощью ON-Bar вы можете проводить резервирование всего экземпляра или отдельных db-пространств. Из архива экземпляра вы сможете восстановить отдельные пространства, весь экземпляр, а при наличии архивов логических журналов – и весь экземпляр на отдельный момент времени. Из архива db-пространств вы сможете восстановить только отдельные db-пространства, хотя логические журналы могут быть использованы для наката транзакций, что повлияет на весь экземпляр. Он-лайн восстановление возможно только для пространств, которые не содержат критических структур Informix Dynamic Server – логических журналов, физического журнала и корневого db-пространства. Если откажет db-пространство, содержащее эти данные, необходимо будет восстанавливать весь экземпляр. Частота и тип бэкапов, создаваемых с помощью ontape, зависят от времени, необходимого для создания бэкапа, допустимого времени восстановления и, в меньшей мере, от скорости ленточного устройства. Ленточные устройства мы рассмотрим чуть ниже. Скорость устройства прямо влияет на длительность создания архива данных, но не очень переживайте, если у вас медленное ленточное устройство. Informix Dynamic Server позволяет создавать бэкапы когда экземпляр находится в он-лайн и обрабатывает запросы пользователей. В обычных условиях процесс резервирования практически не влияет на работу пользователей в системе. Единственный случай, когда процесс резервирования с помощью ontape может повлиять на работу пользователей – это когда устройство резервирования (TAPEDEV) и устройство резервирования журналов (LTAPEDEV) являются одним и тем же устройством и базы данных экземпляра находятся в режиме журналирования. В этом случае возможна ситуация, когда во время создания архива экземпляра, в журналы ведется запись данных. Если не включено динамическое добавление логических журналов (DYNAMIC_LOGS=2), то, если архивирование логических журналов прервано для создания архива экземпляра, экземпляр приостановит работу до того момента, пока логические журналы не будут записаны на ленту. Все пользовательские запросы будут ждать завершения архивирования журналов. После этого экземпляр продолжит работу, и вам будет необходимо перезапустить процесс бэкапа, поскольку он был сорван. Вне зависимости от используемой программы резервирования, существует три уровня гранулярности бэкапов (Таблица 7.1)

Таблица 7.1 Уровни архивов Informix Dynamic Server

Уровень архива

Описание

0 Все используемые страницы экземпляра записываются на ленту

1 Записываются только страницы, измененные с момента создания последнего архива 0-го уровня

2 Записываются только страницы, измененные с момента создания последнего архива 1-го уровня

Ваша задача – поддерживать баланс между тем, чего вы можете достичь с помощью этих трех уровней резервирования, и требованиями к сохранности данных. Для промышленного OLTP я рекомендую следующее:

Базы данных должны находится в режиме небуферизированного журналирования Логические журналы должны архивироваться на ленту непрерывно Ежедневно для экземпляра должен создаваться архив 2-го уровня

В зависимости от ваших предпочтений и времени, необходимого для полного резервирования экземпляра, вы можете создавать архив 0-го уровня первого числа каждого месяца или первого и пятнадцатого числа каждого месяца. В конце недели вы можете создавать архивы 1-го уровня. При таком подходе для восстановления экземпляра понадобится архив 0-го уровня, ближайший архив 1-го уровня (если таковой есть), архивы 2-го уровня и архивы журналов, созданные после выполнения архива 2-го уровня. В следующем разделе мы поговорим о том, как создавать архивы логических журналов. В любом случае вам необходимо определиться, что подходит для вашего окружения. Например, создание архива 0-го уровня дважды в месяц может быть невозможно в вашем окружении из-за стоимости носителей, большого времени, необходимого для выполнения архивирования или чего-нибудь еще. Для OLAP-окружения необходимо учитывать дополнительные факторы. Во-первых, объемы данных гораздо больше, чем в OLTP. Это значит, что процесс резервирования/восстановления занимает больше времени. Во-вторых, при росте хранилища количество изменяемых страниц в базе данных будет уменьшаться. Эти особенности вызывают необходимость изменить схему бэкапа экземпляра. Небуферизированное журналирование и архивирование журналов не так важны в OLAP-системах. Бэкапы можно делать после массового вливания данных в систему. Как я говорил выше, целесообразнее делать не бэкап экземпляра, а бэкап файлов с данными. Естественно, время от времени необходимо выполнять и полное резервирование экземпляра. Например, вы можете делать бэкап 0-го уровня один-два раза в квартал, а не в месяц. Архив 1-го уровня можно делать один раз в месяц, а архив 2-го уровня – один раз в месяц. Восстановление при такой системе бэкапов похожа на описанную для OLTP-систем. Только вместо архива логических журналов необходимо использовать архивы файлов с данными. Вышеизложенное не является единственно правильным решением. Если у вас есть свои наработки в области разработки стратегии архивирования – пользуйтесь ими. Резервирование логических журналов. Как вы читали в Части 6, Informix использует физический и логический журнал для хранения информации об изменениях данных экземпляра. в зависимости от режима журналирования базы данных в журналах может сохраняться очень мало информации (нежурналируемые БД) или практически все, что происходит в БД (журналируемые БД). Эти записи об изменениях данных могут быть очень полезны для вас, если вы хотите иметь возможность восстановления на определенный момент времени. Для большинства систем (за исключением OLAP) потеря транзакций недопустима. Поэтому вам надо знать, как и когда резервировать логические журналы. В зависимости от режима журналирования (буферизированное/небуферизированное) информация транзакций некоторое время в буферах физического и логического журнала, а затем записывается в структуры логического журнала на диске. С течением времени эти журналы заполняются. Когда журналы заполнены и не заархивированы и новые журналы не добавляются, экземпляр записывает в MSGPATH сообщение, что журналы заполнены и приостанавливает работу до окончания архивирования журналов. С учетом вышесказанного вам необходимо принять решение как и когда архивировать журналы. Вариантов три: никогда не архивировать, по требованию, непрерывно

Никогда Чтобы никогда не архивировать логические журналы, установите значение переменной LTAPEDEV равным /dev/null (для версий Informix под Linux, UNIX, Mac OS X) или NUL (Windows). Как только журнал заполняется, он сразу помечается как архивированный и становится доступен экземпляру. Я устанавливаю LTAPEDEV равным /dev/null в тестовых средах, где необходимо иметь журналируемую базу данных, но нет особенной необходимости следить за тестовыми данными. Установка LTAPEDEV равным /dev/null также может иметь смысл в OLAP-системах, где производится мало журналируемых действий. Если вы планируете использовать для резервирования ON-Bar, установка LTAPEDEV равным /dev/null имеете побочные эффекты. ON-Bar устроен так, что необходимо заархивировать все критичные структуры данных экземпляра. Это необходимо не только для успешного восстановления, но и для обеспечения логической целостности экземпляра. Если вы установите LTAPEDEV равным /dev/null,то не сможете использовать ON-Bar для резервирования/восстановления экземпляра. По требованию. В этом случае логические журналы архивируются на ленту командами ontape –a, onbar –b –l (строчная L). Заполненные журналы, как и текущий журнал (as well as the current logical log) записываются на ленту и помечаются готовыми для повторного использования. Этот вариант подходит для экземпляров, содержащих нежурналируемые БД, поскольку в таких системах журналы не заполняются так быстро, что требуется их непрерывное архивирование. В журналируемых БД эту возможность необходимо использовать очень осторожно. Если вы не архивируете своевременно журналы и выключено динамическое добавление журналов, то рано или поздно все журналы заполнятся и экземпляр остановит работу (об этом говорилось выше). Непрерывно В этом варианте после заполнения журнал немедленно архивируется на ленту. Задать такой режим архивирования можно двумя методами. С помощью команды ontape –c, запущенной из окна терминала, подключенного к физическому серверу. Команда запустит фоновый процесс архивирования журналов. Не закрывайте, а просто сверните терминальное окно: в противном случае процесс архивирования журналов прервется. Утилита ontape просигнализирует о заполнении ленты и затребует вставить новую. Второй метод – использование ON-Bar с параметром ALARMPROGRAM и включение автоматического архивирования журналов. По умолчанию этот параметр установлен как $INFORMIXDIR/etc/alarmprogram.sh. В начале скрипта указывается набор конфигурационных параметров: ##### # # PUBLIC SECTION: CONFIGURATION VARIABLES #КОНФИГУРАЦИОННЫЕ ПАРАМЕТРЫ # ##### BACKUPLOGS=N ALARMADMIN=0 ALARMPAGER=0 ADMINEMAIL= PAGEREMAIL= MAILUTILITY=/usr/bin/mail

Если параметр BACKUPLOGS установлен равным Y, скрипт при заполнении журналов автоматически запустит команду onbar –b –l. Обратите внимание, что скрипт проверяет значение LTAPEDEV и если обнаруживает, что оно равно /dev/null (или эквиваленту в Windows), автоматические изменяет значение BACKUPLOGS на N Советы по архивированию логических журналов. Есть много несогласных с интерфейсом утилиты ontape и архивированием логических журналов на магнитную ленту. К сожалению, как мне кажется, альтернативных вариантов нет. Стримеры 4mm DAT достаточно дешевы и быстры для того, чтобы справится с архивированием журналов. Эти устройства могут быть легко подключены к серверу. В последних версиях Informix в утилиту ontape были внесены усовершенствования, позволяющие вместо магнитной ленты использовать каталог на жестком диске (подробнее в следующем разделе). Не забывайте, что для непрерывного архивирования журналов окно терминала должно быть открыто. Если вы не хотите держать постоянно открытым терминальное окно – используйте комплект ON-Bar. Я считаю, что непрерывное архивирование логических журналов является оптимальным выбором для журналируемых БД в промышленных системах. Также не забывайте о влиянии на процесс архивирования наличия BLOB-объектов: простые BLOB-объекты записываются в журналы, что может привести к быстрому заполнению журналов (BLOB types are not considered committed until the simple BLOB information is written to the logical log ). При удалении BLOB-объекта занятое им место освобождается и транзакция подтверждается только после того, как журнал с записью этой операции будет заархивирован. Устройства резервирования Для резервирования с помощью ontape и ON-Bar вы можете использовать как магнитные ленты, так и плоские файлы. Оба варианта имеют свои преимущества и недостатки. Архивирование на ленту наиболее надежно с точки зрения восстановления и предоставляет самый широкий набор опций восстановления. Архивирование в каталог файловой системы может быть подготовительной частью перед большим архивированием, когда заархивированные журналы с файловой системы записываются на ленту. Это необходимо для того, чтобы возможный дисковый сбой не затронул архивы логических журналов. Альтернативой резервированию средствами Informix может быть резервирование средствами файловой системы, т.е. архивирование средствами ОС каталогов с данными (выделенные файлы) или дисковых разделов (сырые пространства). Однако этот подход имеет несколько существенных недостатков. Во-первых, этот метод вызывает дополнительную нагрузку на экземпляр. Некоторые утилиты не бэкапят файлы db-пространств если экземпляр не находится в статическом режиме. По моему мнению, это не может считаться резервированием. Утилиты типа dd в Linux/UNIX/Mac OS X, использующиеся для бэкапа сырых разделов, для правильного применения требуют хорошего знакомства с системным администрированием соответствующих ОС. Эти утилиты во время работы снимают образы страниц вне зависимости от того, используются ли эти страницы в данный момент времени или нет. Во-вторых, при использовании средств ОС не производится проверки согласованности данных. Например, если вы восстановите db-пространство, то вы просто восстановите db-пространство, никакой дополнительной проверки экземпляра проводится не будет. Последствия отсутствия проверки ссылочной целостности – от полного их отсутствия до очень тяжелых, в зависимости от количества затронутых соотношений» главная таблица-подчиненнная таблица». Например, путь было заархивировано пространство, содержащее родительскую таблицу. Затем архивировались другие db-пространства, а в главную и подчиненную таблицу были

вставлены согласованные записи. Подчиненная таблица находится в пространстве, которое архивировалось последним. Если вы восстановите такой архив, то получите в дочерней таблице так называемые осиротевшие строки (строки, которым нет соответствия в главной таблице). мне больше нечего сказать. Используйте средства IDS для резервирования экземпляра – это надежнее и лучше. Ленточные устройства. Сегодня на рынке предлагаются разные технологии бэкапа экземпляров и логических журналов. Традиционно для этих целей используются QIC, 4-миллиметровые кассеты (4mm digital audio tape (DAT)), 8-миллиметровые ленты (8 mm helical-scan tape). Все они имеют свои преимущества и недостатки – от размера самой кассеты до объема данных, которые можно записать на эту кассету. В последнее десятилетие появились новые форматы и устройства, которые могут использоваться для резервирования как таблиц, так и логических журналов. С появлением больших OLTP- и OLAP-систем для их архивирования широко стала применяться DLT-технология (digital linear tape) и подобные ей технологии накопителей большой емкости. Использовать преимущества этих технологий можно с помощью Informix Storage Manager (ISM). Не забывайте, что можно работать одновременно только с 4-мя подключенными локально устройствами (включая плоские файлы). Поддерживаются только «простые» ленточные устройства (подразумевается, что не поддерживаются роботы, авточенджеры и т.п. устройства). ISM поддерживает 4-, 8-миллиметровые ленты, 8mm/5GB-ленты, 3480, 3570,4890, 9490 Timberline, DLT, VHS, QIC, ленты 0.5-дюйма, плоские файлы. При записи на ленту ontape полагается на операционную систему. С одной стороны это плохо, поскольку утилита не обеспечивает прямого доступа к устройству, с другой стороны командой разработки не тратится дорогостоящее время на разработку поддержки расширений ленточных накопителей (различного роботизированного управления и т.п.). Итак, какие устройства можно использовать для резервирования данных с помощью утилиты ontape? Вы можете использовать любое однокассетное ленточное устройство, для которого есть драйвер и которое работает в несжимающем режиме (uncompressed mode). В ontape нет поддержки авточенджеров и прочих опций. Вы должны менять ленты вручную, писать скрипты-оболочки для ontape или, чтобы утилита могла работать с несколькими лентами, перенаправлять ее вывод на стандартное устройство ввода/вывода (STDIO). У новичков в Informix часто возникает вопрос, какой объем данных можно заархивировать, если установлены параметры TAPESIZE, LTAPESIZE. Если архив пишется в файл на диске, то присутствуют все ограничения файловой системы на размер файла (для 32-битных ОС раньше максимальный размер файла был около 2 Гбайт, сейчас больше, для 64-битных ОС максимальный размер файла представляется очень большим числом). При резервировании на ленту ограничение ОС на размер файла не действует, поскольку данные записываются прямо на ленту без участия файловой системы сервера. В этом случае размер архива ограничен только емкостью кассеты. Итак, ограничения ontape таковы:

1. Если параметры TAPEDEV или LTAPEDEV указывают на плоские файлы, то максимальный размер файла в ОС

2. Если параметры TAPEDEV или LTAPEDEV указывают ленту, то емкость ленты В другом случае размер данных не должен превышать 4Тбайт

Установка TAPEDEV или LTAPEDEV в /dev/null приводит к выполнению бэкапа за несколько секунд. Когда TAPEDEV установлен равным /dev/null , то при выполнении операции бэкапа в экземпляре изменяются необходимые флаги на служебных страницах и на этом бэкап прекращается. Эта методика полезна, когда необходимо изменить режим журналирования базы данных или когда вы хотите заархивировать и закрыть текущий логический журнал, чтобы активировать созданное BLOB-пространство. В этом случае вам не нужно корректировать размер ленты и размер блока, так как сервер игнорирует эти параметры. Мне кажется, не нужно говорить, что восстановить что-либо из архива, записанного в /dev/null, нельзя. При выборе ленточного устройства для ontape есть еще одно ограничение – устройство при открытии/закрытии не должно автоматически перематывать ленту. Перед записью на ленту или считыванием с нее ontape проводит серию проверок, одна из которых как раз и является перемоткой ленты. Есть еще один метод быстрого бэкапа, который не требует махинаций с файлом $ONCONFIG – это возможности ON-Bar и ontape по выполнению «fake» бэкапа. Вы можете выполнять «fake» бэкап даже когда ISM и/или ON-Bar не сконфигурированы. Дальше в этой части я расскажу, как выполнять «fake» бэкапы. Бэкап в каталог. Бэкапы экземпляра и логических журналов можно хранить на диске. Как вы понимаете, это добавляет элемент риска в процедуру бэкапа. Хранение бэкапов на жестком диске не избавляет от необходимости архивировать содержимое этого диска на ленту или другое устройство. Если диск сломается – бэкапов у вас не будет. Если на диске еще были чанки баз данных, то у вас точно будут крупные неприятности. Если вы бэкапитесь средствами IDS на диск, то после этого бэкапа вам необходимо архивировать каталог средствами ОС. При архивировании на диск, создаваемые файлы и их расположение сильно зависят от используемой программы архивирования. Ниже мы рассмотрим конфигурирование ISM и вы увидите, что необходимо задать имя каталога для архивов экземпляра и архивов логических журналов. При выполнении бэкапа средствами ON-Bar для каждого db-пространства создается отдельный файл. Это же справедливо и для архивирования логических журналов. В именах файлов бэкапов содержатся числа, которые увеличиваются при бэкапе каждого db-пространства или журнала. Стартовое значение генератора этих числе равно 15800, и изменить его вы не сможете, как не сможете и изменить имена создаваемых файлов. Как вы увидите ниже, имена файлов хранятся в контрольных файлах ON-Bar и ISM и используются во время процесса восстановления. При использовании ontape у вас есть три возможности. Во-первых вы можете указать полное имя файла в качестве значения TAPEDEV и/или LTAPEDEV. Например. TAPEDEV /data/tagus_inst_bkup LTAPEDEV /data/tagus/logical_bkup В этом случае ontape при создании бэкапа экземпляра или логического журнала переписывает существующий файл. Поэтому не забывайте перед началом бэкапа сбросить на ленту или еще куда-нибудь предыдущий файл бэкапа. Одно маленькое исключение из вышеизложенного – непрерывное архивирование журналов на диск с помощью команды ontape –c. В этом случае на файл ставится блокировка и бэкапы дописываются в конец файла (a lock is placed on the file and the file itself appended until the backup is interrupted). В этом случае также необходимо не забывать после прерывания непрерывного архивирования журналов записать файл архивов на ленту.

Вторая возможность – установить TAPEDEV равным STDIO (стандартный ввод/вывод). Также, чтобы переопределить значение TAPEDEV в файле$ONCONFIG, можно запустить ontape с ключом –t STDIO. Если бэкап производится на STDIO, поток данных записывается в системный «пайп» (system pipe) и может быть перехвачен другой программой и обработан необходимым образом. Например, вы можете передать этот поток данных скрипту, который будет писать его в файл: ontape –s –L 0 | my_bkup_util.sh –t STDIO Или, если TAPEDEV установлен в STDIO, то поток данных можно передать утилите сжатия: ontape –s –L 0 | gzip>/data/bkups/mon_bk_L0.gz Я чаще всего использую такой подход для одновременного выполнения архивирования на одном сервере и восстановления данных на другом. Это необходимо для запуска репликации данных высокой доступности (High Availability Data Replication HDR) или на экземплярах MACH-11: ontape –s –L 0 | rsh зеркальный_сервер “ontape-p” В IDS 11 появилась возможность установить в качестве значения параметров TAPEDEV и LTAPEDEV путь к каталогу и предоставить серверу заниматься именованием файлов. Когда для TAPEDEV или LTAPEDEV установлен каталог, например, /opt/IBM/Informix/backups/ то при выполнении бэкапа ontape создает файл в указанном каталоге. Поскольку размер файла, создаваемого ontape, не может превышать 4 Тбайта или максимального размера файла, поддерживаемого ОС, вероятнее всего при бэкапе будет создан один файл. При именовании файлов используется схема именования по умолчанию, которую вы можете переопределить. По умолчанию имя бэкапа экземпляра составляется из трех частей:

Физического имени сервера Значения DBSERVERNUM архивируемого экземпляра Уровня бэкапа с префиксом L

При использовании ontape в целевой директории будут созданы файлы примерно с такими именами (я убрал информацию о правах, владельце файлов и т.п) Jan 26 03:51 nichole_123_L0 Jan 27 00:34 nichole_123_L1 Если в каталоге есть предыдущий файл бэкапа такого же уровня, то он переименовывается путем приписывания к имени временной метки. Таким образом, вы можете всегода найти последний бэкап требуемого уровня – он содержит в имени суффикс Ln, где n – уровень бэкапа Jan 25 04:34 nichole_123_20080125_043421_L1 Jan 26 03:51 nichole_123_L0 Jan 27 00:34 nichole_123_L1

Схема именования архивов логических журналов примерно такая же. В третьей позиции содержится слово Log и 10-символьный номер. Например, Jan 26 03:51 nichole_123_Log0000000387 Не знаю, как вы, а я не могу запомнить DBSERVERNUM при обращении к экземплярам. Я стараюсь использовать имена или псевдонимы экземпляров. С помощью переменной окружения IFX_ONTAPE_FILE_PREFIX вы можете переопределить строку, которую нужно использовать при именовании архивов. Имена айлам архивов даются на основе этой строки и уровня бэкапа или номера логического журнала: Jan 15 14:57 mproduction_20080115_145734_L0 Jan 16 15:14 mproduction_20080116_151436_L0 Jan 26 23:51 mproduction_L0 Jan 27 00:34 mproduction_L1 Jan 26 19:59 mproduction_Log0000000008 Jan 26 19:59 mproduction_Log0000000009 Конфигурационные параметры ontape перечитываются при запуске утилиты. Это значит, что вы можете менять их без перезапуска экземпляра, что позволит вам гибко выполнять административные задачи. Например, чтобы активировать добавленное BLOB-пространство, необходимо выполнить бэкап. Вы можете временно установить TAPEDEV в /dev/null, выпонить бэкап и вернуть значение параметра на место. Вторая возможность – выполнить «fake»-бэкап средствами ontape или ON-Bar. Как работает процесс резервирования Сейчас мы рассмотрим вопрос – как Informix создает архивы различных уровней в тот момент, когда экземпляр находится он-лайн и обслуживает запросы пользователей. Такое поведение возможно благодаря структуре заголовка страницы данных (page header). В этом разделе я кратко расскажу, как работает процесс он-лайн архивирования. Алгоритм справедлив для любой утилиты, используемой для бэкапа. Рассмотрим процесс на примере ontape. При изменении элемента на странице данных на этой же странице изменяется временная метка (time stamp). Отношение временной метки одной страницы и другой страницы определяет, какая страница была изменена раньше – первая или вторая. Сервер также использует временную метку для определения, была ли страница модифицирована до или после некоторого момента времени. это ключ к созданию он-лайн бэкапов. При инициализации бэкапа любого из трех уровней первой выполняется обработка контрольной точки (checkpoint). Она сбрасывает все буфера на диск и синхронизирует буфера логического журнала для баз данных с буферизированным журналированием. Затем сервер устанавливает то, что я называю временной отметкой бэкапа (backup time stamp) экземпляра. Это момент времени, когда завершилась обработка контрольной точки, и с этим моментом времени процесс бэкапа сравнивает временные отметки страниц для определения, необходимо ли архивировать эту страницу. В зависимости от уровня архива процесс бэкапа будет обрабатывать такие страницы:

Страницы с более поздней временной отметкой, чем временная отметка бэкапа подходящего нижнего уровня (of a previous backup of the appropriate lower level). Это актуально для бэкапов 1,- и 2-го уровня. Например, бэкап первого уровня будет обрабатывать только страницы, изменившиеся с момента создания

последнего бэкапа 0-го уровня, бэкап 2-го уровня будет обрабатывать только страницы, изменившиеся с момента создания последнего бэкапа 1-го уровня.

All used pages but the pages copied will be as they were when their page time stamp was older than or equal to the backup time stamp, as occurs in a level 0 backup

Процесс бэкапа просматривает каждую страницу данных в чанке, и на основании временной метки страницы определяет, необходимо ли бэкапить страницу. Если да, то страница обрабатывается с помощью соответствующего API. Что происходит в тот момент, когда следующий чекпоинт (обработка контрольной точки) меняет страницы, которые еще не заархивированы? Именно в этом случае в игру вступает физический журнал. Перед тем, как чекпоинт сбросит все данные на диск, ontape или ON-Bar просматривает страницы в физическом журнале. Если страница должна быть заархивирована, то ничего больше не происходит, и программа архивирования переходит к следующей странице физического журнала. Если следующая страница принадлежит чанку, который еще не был заархивирован, утилита переходит к этой странице и оценивает ее временную отметку. Если, согласно временной отметке, страницу необходимо архивировать, она немедленно архивируется. После того, как все страницы физического журнала прочитаны и все соответствующие страницы данных заархивированы, обработка контрольной точки продолжается, и процесс бэкапа продолжается с того места, где он остановился перед началом чекпоинта. В процессе обработки контрольной точки обновляются временные отметки всех измененных страниц. Бэкап с помощью ontape обрабатывает чанки в порядке их создания. ON-Bar может эмулировать такое поведение, а может работать и в параллельном режиме. Параллельный режим работы ON-Bar задается командой onbar –b, а последовательный режим – onbar-b –w. В IDS 11 в работу ON-Bar были внесены значительные изменения, о которых необходимо рассказать. Как говорилось выше, ontape обрабатывает чанки в порядке их создания, начиная с корневого db-пространства. В версиях Informix младше 11 ON-Bar в последовательном режиме работал точно также. Параллельный режим работы, естественно, совсем другая песня. Если у вас было сконфигурировано несколько устройств резервирования, то с помощью команды onbar –b вы могли выполнять параллельно резервирование нескольких db-пространств. Каждое db-пространство имело свою собственную временную отметку о бэкапе и бэкапилось отдельно от других. Процесс резервирования использовал эти временные метки для определения того, находятся ли в db-пространстве страницы данных, которые необходимо архивировать. При обработке контрольной точки во время бэкапа также использовался и физический журнал В результате использования такого алгоритма параллельного резервирования при восстановлении данных требовалось восстановить и db-пространства, и логические журналы. После восстановления всех пространств до их временной отметки было необходимо восстанавливать журналы до временной отметки последнего забэкапленного пространства. Количество времени на восстановление зависело от количества пространств, количества транзакций, прошедший во время создания бэкапа, использованной степени параллелизма и т.п. В IDS 11 в этот процесс были внесены два значительных изменения. Первое: и при параллельном, и при последовательном резервировании ON-Bar использует одну временную метку. В результате для восстановления теперь не требуется накатка журналов (logical roll-forward). Второе изменение: при парцелльном резервировании ON-Bar использует другие алгоритмы обработки пространств. Старые версии обрабатывали чанки в порядке их создания, в IDS 11 пространства обрабатываются в зависимости от занимаемого ими размера.

В IDS 11 вы можете установить параметр BAR_MAX_BACKUP больше 0 (ноль), и экземпляр будет изменять порядок бэкапа чанков так, чтобы минимизировать время выполнения операции. Чтобы эффективно использовать эту возможность необходимо, чтобы значение параметра соответствовало количеству устройств резервирования. По умолчанию система использует значение параметра равное 4. На рисунке 7.2 приведена графическая иллюстрация нового функционала.

Рисунок 7.2 Пример упорядочивания db-пространств во время бэкапа В этом примере необходимо забэкапить 7 db-пространств, время бэкапа каждого пространства указано внутри прямоугольника. Без упорядочения пространства резервируются в порядке их создания, что значит, что большое пространство резервируется последним. Если используется упорядочение, то большие db-пространства резервируются в начале процесса бэкапа (самым первым всегда бэкапится корневое db-пространство). В этом случае процесс заканчивается на 10 минут раньше. При возрастании количества db-пространств и их размера переупорядочение пространств перед их резервированием становится еще более выгодным. Оно позволяет IDS использовать возможности распараллеливания операций (при наличии нескольких устройств резервирования), сокращает время создания и восстановления бэкапа. Как вы видите, резервирование средствами Informix – это получение моментального снимка контекста экземпляра. Информация о двух последних бэкапах разных уровней хранится на двух последних зарезервированных страницах корневого db-пространства. Просмотреть хранимые данные (уровень бэкапа, время создания бэкапа, временную отметку, информацию о текущем логическом журнале в момент старта бэкапа) можно с помощью команды oncheck –pr

Опции восстановления При восстановлении из бэкапа возможны две опции. Вы можете восстанавливать весь экземпляр; этот процесс называется холодное восстановление (cold restore) , а также вы можете восстанавливать отдельные db-пространства (теплое восстановление или warm/online restore). Холодное восстановление проводится в случае катастрофического дискового сбоя, который зацепил и повредил корневое db-пространство, физический журнал или одни из логических журналов. Экземпляр немедленно переходит в состояние офф-лайн, из которого вывести его невозможно. В этом случае единственным выходом является полное восстановление или переинициализация экземпляра. Если дисковый сбой зацепил другие db-пространства или вам просто необходимо восстановить пространство (не корневое и не пространство, содержащее журналы), вы можете выполнить теплое восстановление. Это восстановление можно проводить при работающем экземпляре, но необходимо, чтобы восстанавливаемые db-пространства были отключены (смотрите в части 5 как изменить статус чанка или db-пространства). В IDS 10 появился новый тип восстановления данных – восстановление на табличном уровне (point-in-time table-level restore). Этот тип восстановления использует функциональность программы archecker для выделения из бэкапа содержимого одной или нескольких таблиц и восстановления этих данных в одну или несколько таблиц. В этом разделе мы рассмотрим все три возможности восстановления. Перенаправление восстановления (redirected restores) Эта возможность не является полноценной опцией восстановления, но упомянуть об этом новом функционале ontape и ON-Bar необходимо. Раньше операция восстановления была абсолютной (в терминах целевого пространства и места, где оно было создано), т.е. восстановление было возможно только туда, откуда был создан бэкап. Это вторая причина использования символических ссылок, а не абсолютных путей. Можно изменить физические устройства и файлы, но пути, с которыми оперирует IDS, остаются в этом случае неизменными. Недавно стало возможным перенаправлять поток данных. Например, если исходный путь к чанку был /opt/IBM/informix/inst_1/some_name, то можно перенаправить восстановление в /ifmx_data/dif_inst/chunk_1. Изначальная цель этой возможности – восстановить бэкап, полученный на сервере А, на совместимый сервер Б, даже в том случае, когда не совпадают абсолютные физические пути. Вы можете использовать эту возможность и на одном сервере, когда вам необходимо провести восстановление, но нет возможности воссоздать символические ссылки или когда этих ссылок вообще не существует. Эта возможность восстановления присутствует в ontape и ON-Bar и требует для своей работы указания данных о старом устройстве (путь и смещение) и новом устройстве (путь и смещение). Кроме флагов –p и –n (указание старого и нового пути и смещения) в ontape и ON-Bar можно также указывать флаг –rename. В командной строке можно указать столько устройств, сколько вам необходимо. Но такой подход увеличивает вероятность ошибки. В качестве альтернативы можно использовать флаг чтения из файла, в котором указана та же информация об устройствах. Использование ontape Вы можете использовать ontape для резервирования и восстановления всего экземпляра Informix Dynamic Server или его части, а также для архивирования и восстановления логических журналов. В этом разделе мы рассмотрим эти операции. Вы увидите одно из преимуществ использования этой утилиты – простоту. Ontape можно использовать сразу же после установки, и она не нуждается в длительной и сложной настройке.

Создание бэкапов (включая fake-бэкапы) Итак, сначала давайте рассмотрим процесс бэкапа логических журналов. Как я говорил выше, журналы можно бэкапить постоянно или по требованию (continuously or on-demand). Для бэкапа по требованию выполните команду ontape –a. Эта команда копирует заполненные журналы на ленту и затем спрашивает, хотите ли вы забэкапить и текущий журнал. Если вы ответите утвердительно, то информация о транзакциях перестанет записываться в текущий журнал, и он будет записан на ленту, вне зависимости от того, сколько в нем еще осталось свободного места. После этого следующий свободный журнал становится активным, и информация о транзакциях начинает писаться в него. Для постоянного бэкапа логических журналов используется команда ontape –c. Эта команда запускает фоновый процесс архивирования логических журналов. После того, как лента заполнена на LTAPESIZE, в окне, откуда был запущен процесс бэкапа, появится сообщение о необходимости вставить новую ленту. Используя возможности IDS 11 вы можете выполнять бэкап журналов в каталог на жестком диске. Теперь давайте рассмотрим архивирование всего экземпляра. Единственный необходимый флаг – уровень бэкапа. В ниже приведенном синтаксисе уровень_бэкапа необходимо заменить числами 0 (ноль), 1 (единица), 2. ontape –s –L уровень_бэкапа В команде могут использоваться и другие флаги. Некоторые из них приведены в таблице 7.2

Таблица 7.2. Флаги бэкапа утилиты ontape

Флаг Описание

-F Создание «fake»-бэкапа. Бэкап не происходит, устанавливаются флаги-индикаторы завершения бэкапа. Полезная опция для активации созданных BLOB-пространств.

-t STDIO Переопределяет параметр TAPEDEV и перенаправляет поток данных на стандартный ввод/вывод для перехвата процессом ОС

-v Включает «verbose mode», в котором выводится информация о статусе операции бэкапа

-y Утвердительный ответ на все вопросы. Может быть полезно в том случае, когда вы пытаетесь заскриптовать операции ontape на устройство, отличное от каталога (if you are trying to script ontape operations to devices other than a directory)

В таблице не рассмотрена еще одна группа флагов. Как вы помните из Части 5, при изменении режимов журналирования БД выполняется бэкап 0-го уровня. Если необходимо изменить режим журналирования нескольких БД экземпляра, то можно применить утилиту ondblog, использование которой не требует выполнения бэкапа 0-го уровня каждой БД, для которой изменяется режим журналирования. Утилита ondblog выставляет флаги изменения режима журналирования. Эти изменения применяются после выполнения бэкапа 0-го уровня.

Когда выполняется резервирование экземпляра, на экран выводится процент завершения операции. Обратите внимание, выводимые цифры не являются абсолютно точными. Восстановление из бэкапа Синтаксис команды восстановления довольно прост, например, холодное восстановление делается так: ontape –r Для восстановления определенного db-пространства используется команда: ontape -r –D имя_db_пространства Если необходимо восстановить несколько db-пространств, то можно перечислить их имена через пробел. Утилита ontape не поддерживает восстановление на определенный момент времени (ontape does not support moment-it-time restores per se). Возможно восстановление до определенного логического журнала (you are restricted to a logical log level of granularity). Во время восстановления вы можете остановить процесс после восстановления бэкапа определенного уровня. Или можете принять приглашение и вставить ленту с бэкапом следующего уровня или с бэкапом логических журналов. Поскольку при бэкапе и восстановлении средствами ontape используются временные метки, в конце операции восстановления вы получите базу данных в целостном состоянии. Как говорилось выше, вы можете перенаправить поток данных одного или нескольких db-пространств. Синтаксис такой: -rename [-f путь_к_файлу | -p исходный_путь \ -o исходное_смещение –n новый_путь –o новое_смещение] Использование ON-Bar и Informix Storage Manager В процессе разработки IDS, увеличения и усложнения баз данных, стало ясно, что заказчикам нужен более гибкий инструмент, чем ontape. В этой части мы рассмотрим именно такой инструмент. Комплект программ ON-Bar и ISM Как упоминалось в Части 4, комплект ON-Bar, Informix Storage Manager и Tivoli Storage Manager (TSM) являются необязательными (опциональными) компонентами. По умолчанию они устанавливаются, но вы можете и отказаться от установки. Комплект ON-Bar и ISM – это не первая попытка разработать улучшенный программный комплекс резервирования данных. Первая разработанная программа была не слишком удачной и после года или двух эксплуатации ее развитие и поддержка были прекращены. Вместо нее был разработан комплекс ON-Bar (ONLine Backup And Restore). ON-Bar – реализация клиентского компонента системы Open Systems Backup Services Data Movement (XBSA), которая разработана X/Open. Изначально ON-Bar представлял собой интерфейс к сторонним менеджерам хранения, но вскоре менеджер хранения был включен в состав сервера БД. ISM был предназначен для пользователей, которым не требовалась система управления лентами уровня предприятия (enterprise-wide tape management solution). ISM поставляется в составе сервера, хотя с течением времени не предпринимались шаги по улучшению его работы. Планируется, что в последующих релизах IDS ISM больше не будет, но когда именно это случится – никто не знает. В составе сервера IDS

поставляется клиентская часть Tivoli Storage Manager для выполнения архивирования данных с помощью этого продукта. Интерфейс X/Open XBSA API был создан для того, чтобы приложения выполняли операции бэкапа/восстановления через стандартный интерфейс без привязки к какой-то платформе. Он обеспечивает 5 основных функций:

Одновременный бэкап и/или восстановление любых данных в гетерогенной среде. Возможность поиска определенного объекта бэкапа для его восстановления (the

ability to search for a given backup object to initiate a restore operation) Масштабируемость. Возможность обрабатывать данные любого размера Поддержка гетерогенных платформ и сетей. Возможность конфигурировать и запускать операции бэкапа и восстановления

независимо, чтобы выполнение одной операции не влияло на выполнение второй. Интерфейс состоит из четырех основных компонентов (рисунок 7.3):

Клиент XBSA. Обслуживает запросы XBSA Manager на прием/получение данных Менеджер XBSA (XBSA manager). Этот компонент обслуживает взаимодействие

между ПО бэкапа и клиентским компонентом. Обеспечивает интерфейс к каталогу базы образов (image database catalog), который обслуживается компонентом службы бэкапа (Backup Service)

Служба бэкапа (Backup Service). Этот компонент непосредственно обслуживает операции чтения/записи устройства хранения. Также занимается базой данных образов бэкапа.

Приложение XBSA (XBSA application). Обобщенное название приложения, использующего API. Может относиться к клиенту XBSA и менеджеру XBSA

Рисунок 7.3. Обзор компонентов XBSA В реализации IBM в роли клиента XBSA выступает набор утилит ON-Bar, а ISM работает как менеджер XBSA и служба бэкапа. ON-Bar называется набором утилит, поскольку состоит из двух утилит:

onbar – исполняемый файл, расположен в каталоге $INFORMIXDIR/bin. Для своей работы вызывает драйвер onbar_d. В Windows – это .bat-файл

onbar_d. Драйвер, который непосредственно взаимодействует с менеджером хранения (storage manager) и непосредственно выполняет обработку данных во время бэкапа/восстановления.

После выхода ON-Bar группа разработчиков IDS прекратила попытки написать систему управления бэкапами. С помощью ON-Bar сервер может взаимодействовать с различными менеджерами хранения и допускает резервирование/восстановление отдельных db-пространств, целых экземпляров и логических журналов. В некоторых случаях восстановление может быть выполнено по состоянию на конкретное время. Функциональное взаимодействие элементов системы резервирования IDS показано на Рисунке 7.4. Комбинация ON-Bar и ISM позволяет выполнять параллельное резервирование на несколько устройств (их число ограничено).

Рисунок 7.4. Функциональная схема взаимодействия ON-Bar и ISM. Перед использованием ISM или любой другой системы управления лентами следует ознакомиться с используемой терминологией.

Сохраненный набор (Save set) – логическое имя данных, забэкапленных в процессе операции резервирования

Устройство (Device) –физическое устройство, на котором создается сохраненный набор. Существует два базовых класса устройств – лента и файл. В зависимости от характеристик сервера один сохраненный набор может быть создан на нескольких устройствах различных типов. ISM ограничивает вас 4-мя устройствами. Если требуется больше – купите другую систему управления лентами. Опыт показывает, что в ISM нежелательно использовать более 2-х устройств типа «файл»

Том бэкапа (Backup volume) – также известен как том. Это устройство, на которое непосредственно записывается бэкап (магнитная лента, файл на диске и т.п)

Отдельное устройство (standalone device) – отдельное устройство хранения без автоматического обслуживания ленты. ISM поддерживает только такие устройства, поэтому вам будет необходимо менять руками ленты во время операций бэкапа и восстановления.

Имя тома (volume name) – логическое имя тома бэкапа. Пул томов (volume pool) – логическое имя набора томов. При использовании ISM

создание пулов томов является стандартной практикой. Например, вы можете

создать один пул для бэкапов экземпляров, второй пул – для резервирования логических журналов. Каждый пул будет содержать свой уникальный набор томов.

Метка тома (volume label) – логический идентификатор, записывается ISM на том. Используется для идентификации медиа-устройства в пуле томов. В имени метки как составная часть используется имя пула. По умолчанию все метки томов становятся недействительными через два года. Когда метка становится недействительной, ISM блокирует запись на такое устройство, но позволяет считать с него данные.

Каталог ISM (ISM catalog). Собственная база данных ISM. Включает в себя информацию о сохраненных наборах, пулах томов и т.д. Эот каталог в процессе бэкапа записывается на том в пуле ISM_DATA_POOL.

Загрузочный файл (bootstrap file). Является частью каталога ISM. Этот файл требуется для восстановления каталога ISM после катастрофического сбоя. Он архивируется (как отдельный объект) при выполнении каждой операции бэкапа средствами ON-Bar. По умолчанию этот файл записывается на том пула ISMData. Если вы планируете резервировать ваш экземпляр в другой пул томов, то ниже я объясню, как сконфигурировать бэкап загрузочного файла и некоторых других объектов. Это очень критичные файлы, поэтому к их бэкапу надо подойти ответственно.

Период сохранения (retention period) – период времени, на протяжении которого информация о сохраненном наборе содержится в каталоге ISM. По окончании этого времени все данные о наборе удаляются из каталога ISM. Если вам необходимо провести восстановление из набора, данные о котором были удалены из каталога ISM, то можно пойти двумя путями: восстановить соответствующий бэкап каталога ISM, в котором содержится запись об этом наборе, или восстановить только информацию о сохраненном наборе и обновить каталог ISM командой ism_catalog –recreate_from

Статус переработки (recycle status). Указывает, все ли сохраненные наборы, записанные на определенный том, истекли и готов ли том к повторному использованию. По умолчанию период задается для всех томов и, следовательно, влияет на статус любого тома, но вы можете отключить устаревание тома установив его статус переработки в manual. Такая установка сохраняет информацию о томе в каталоге ISM до тех пор, пока вы вручную не очистите том.

Клоны (clones). С помощью ISM вы можете создавать копии целых томов или сохраненных наборов. Клоны наследуют все характеристики оригинала, поэтому если вы, например, клонируете сохраненный набор, который скоро истекает, клон истечет ровно в то же время.

Механизм резервирования и восстановления средствами ON-Bar поддерживается несколькими структурами БД. Я уже упоминал о каталоге ISM, где хранится информация о сохраненных наборах, периоде сохранения. Кроме этого, для поддержки и отслеживания операций ON-Bar используется набор таблиц базы данных sysutils. Если хотите узнать, зачем нужны эти таблицы, можете взглянуть на скрипт их создания в каталоге $INFORMIXDIR/etc или почитать IBM Informix Backup and Restore Guide. В двух словах, таблица bar_action используется для отслеживания успешности/неуспешности выполнения операций бэкапа и восстановления. Таблица bar_instance отслеживает успешные операции бэкапа. Она связана с каталогом ISM. Таблица bar_object содержит список всех объектов БД (db-пространства, BLOB-пространства, логические журналы), которые резервируются средствами ON-Bar. Вооружившись теорией, давайте рассмотрим конфигурирование ON-Bar и ISM для выполнения бэкапа и восстановления экземпляра и логических журналов.

Конфигурирование ON-Bar и ISM Несколько параметров файла $ONCONFIG отвечают за ISM или взаимодействие ON-Bar с какой-либо третьей системой управления лентами. Эти параметры кратко описаны в Таблице 7.3

Таблица 7.3. Параметры конфигурации ON-Bar

Параметр Описание

BAR_MAX_BACKUP Количество потоков данных, выводимых на устройства бэкапа при выполнении параллельного бэкапа. Устанавливается равным количеству доступных ленточных/дисковых устройств бэкапа

BAR_XFER_BUF_SIZE Используется для вычисления объема памяти, используемой для транспортных буферов. Это целое число количества страниц. Максимальное значение – 64 Кбайта. Максимальное значение этого параметра получаю разделив 64 на максимальный размер страницы db-пространства (в КБт). Например, если вы используете 8 Кбайтные страницы то значение будет равно 8.

ISM_DATA_POOL Опциональный параметр. Определяет пул томов, используемый для бэкапа экземпляров.

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

BAR_NB_XPORT_COUNT Определяет количество буферов данных, которые будет использовать каждый поток ON-Bar для пересылки данных между экземпляром и системой управления лентами

BAR_PERFORMANCE Имеет диапазон значений от 0 (ноль) до 4. определяет, какая статистическая информация выводится в журнал ON-Bar

BAR_RETRY Если провалилась первая попытка выполнения операции ON-Bar, то сколько раз пытаться выполнить операцию

BAR_BSALIB_PATH Опциональный параметр. Определяет путь к разделяемой библиотеке системы управления лентами. Эта разделяемая библиотека используется ON-Bar API для обмена данными между экземпляром и системой управления лентами

Как я уже говорил, важна правильная установка параметра LTAPEDEV. Если вы планируете использовать ON-Bar для резервирования логических журналов, LTAPEDEV не может быть установлен равным /dev/null или аналогу в Windows. В противном случае когда журналы заполняются, экземпляр автоматически пометит их как забэкапленные. Установка этого параметра равным /dev/null также не дает выполнить бэкап экземпляра. При подготовке к запуску ON-Bar необходимо корректно установить вышеупомянутые параметры и настроить систему управления лентами, которую вы будете использовать. Описание настройки таких систем заслуживает отдельной большой книги, поэтому для примера мы будем использовать стандартный ISM. Сначала необходимо указать системе, где находится разделяемая библиотека интерфейса к системе управления лентами. Сделать это можно несколькими путями. Во-первых, можно использовать конфигурационный параметр BAR_BSALIB_PATH. В качестве его значения необходимо прописать полный путь к разделяемой системной библиотеке.

Во-вторых, можно пересоздать символическую ссылку $INFORMIXDIR/lib/libsad001.platform_extension и перенаправить ее на необходимую системную библиотеку. В-третьих, можно включить каталог, в котором хранится необходимая библиотека, в LD_LIBRARY_PATH. Библиотека ISM находится в каталоге $INFORMIXDIR/lib и называется libbsa.расширение_платформы. Поэтому проще будет использовать первую или вторую возможность. Файл может и не существовать изначально, а создаваться в результате выполнения нижеописанного шага. Необходимо также установить и сконфигурировать систему управления лентами. В случае ISM для этого необходимо от имени root выполнить команду ism_startup –init (находится в каталоге $INFORMIXDIR/bin). Эта команда запишет в каталог $INFORMIXDIR/ism несколько исполняемых файлов и библиотек и создаст файл sm_versions в каталоге $INFORMIXDIR/etc. В этом файле должна быть запись о используемой вами системе. Формат файла описан в IBM Informix Backup and Restore Guide. ISM, как и любая другая система управления лентами, является отдельным приложением и может не запускаться в процессе запуска экземпляра. Если вы хотите запускать(ism_starup) или останавливать (ism_shutdown) ISM в процессе включения или выключения физического сервера, необходимо соответствующим образом изменить каталоги /etc/rc2.d и /etc/rc0.d. После запуска ISM вы можете предоставить привилегии администратора пользователю, который будет выполнять операции ISM. Делается это нижеследующей командой: ism_add –admin id_пользователя@имя_хоста Если вы установили сервер с разделением ролей, возможно захотите добавить учетные записи, определенные во время инсталляции, к списку пользователей, которым разрешено изменять конфигурацию ISM. Установка свойств сервера. Вероятно, самое важное свойство, которое необходимо установить, это количество времени до истечения сохраненного набора. Период сохранения зависит от вашей стратегии резервирования. Если вы используете комбинацию полного и инкрементального бэкапа и создаете на протяжении недели полный бэкап экземпляра, то можно установить период сохранения равный нескольким неделям. Количество недель зависит от того, на сколько недель вам, возможно, потребуется вернуться назад, чтобы восстановить какой-то элемент данных. Можно также добавить некоторое время на то, что я называю «Вот черт возьми». Этот фактор возникает в том случае, когда какая-то лента запорчена и необходимо вернуться к более раннему бэкапу. При установке времени устаревания (expiration period) обратите внимание, что не все сохраненные наборы автоматически устаревают в конце этого периода. Предположим, что вы установили период устаревания равным 5 дней и в понедельник создали бэкап 0-го уровня, а в четверг – бэкап 2-го уровня. Бэкап 0-го уровня устареет в субботу, но он останется активным до тех про, пока не произойдет одно из двух: пройдет еще три дня без создания других инкрементальных бэкапов (за это время устареет бэкап 2-го уровня) или не будет создан бэкап 0-го уровня. Сохраненный набор не устаревает до тех пор, пока не устареют все зависящие от него наборы, необходимые для восстановления экземпляра. При необходимости вы можете переопределить запланированную дату устаревания. Для этого необходимо установить recycle status тома равным manual, а не automatic. Когда ISM запущен базовые настройки можно увидеть с помощью команды ism_show –config.

Изменить конфигурационные параметры можно с помощью команды ism_config, например, ism_config –retention количество_дней ism_config –streams количество_потоков В ISM максимальное количество потоков равно 4. В другой системе управления лентами количество потоков должно соответствовать количеству устройств, которые применяются при резервировании и восстановлении. Файлы журналов Файлы журналов помогают в мониторинге различных аспектов работы ISM и ON-Bar. Журнал работы ON-Bar В этом журнале содержатся записи об операциях ON-Bar. Имя файла и его месторасположение задается переменной BAR_ACT_LOG файла $ONCONFIG. Журнал отладки и уровень отладки ON-Bar Этот опциональный журнал используется службой технической поддержки IBM для диагностики проблем при работе с ON-Bar. Для его использования необходимо задать полный путь к журналу в переменной BAR_DEBUG_LOG файла $ONCONFIG. Кроме этого, необходимо установить значение переменной BAR_DEBUG. Диапазон значений этой переменной 0-9. С уровня 7 в файл журнала пишется очень много данных, поэтому для предотвращения проблем переполнения файловой системы необходимо контролировать размер файла журнала. Журнал ISM Server Этот журнал находится в файле $INFORMIXDIR/ism/logs/daemon.log. в него записываются все операции ISM. С помощью команды tail –f вы можете просматривать в реальном времени, как ISM соединяется со своими демонами, открывает каталог ISM и монтирует тома для выполнения бэкапа или восстановления. Журнал сообщений Legato ISM был лицензирован у компании Legato. Сообщения от Legato записываются в журнал расположенный в $INFORMIXDIR/ism/logs/messages. В этот же каталог пишется список бэкапов каталога ISM. Информация из этого списка критична для восстановления после сбоя. Журнал и уровень отладки ISM В этот журнал записывается отладочная информация ISM. Находится в каталоге $INFORMIXDIR/ism/applogs/xbsa.messages. Уровень подробности отладочной информации задается параметром ISM_DEBUG_LEVEL в файле onbar, который в свою очередь расположен в каталоге $INFORMIXDIR/bin. Этого параметра нет в файле, его необходимо добавить самостоятельно. Допустимые значения параметра: 0-9. Этот параметр можно указать только водном месте файла – в самом конце в секции «add startup processing here». Для отключения журналирования ISM можно либо закомментировать этот параметр, либо установить его равным 0 (ноль). Изменение уровня журналирования требует перезапуска ISM (ism_shutdown/ism_restart). Этот параметр можно установить с помощью переменной окружения (описано в IBM Informix Storage Manager Administration Guide).

Конфигурирование устройств хранения Перед началом использования ON-Bar необходимо сконфигурировать одно или несколько устройств хранения. ISM поддерживает максимум 4 устройства, это значит, что параллельно вы можете архивировать 4 db-пространства. Перед началом конфигурирования устройства убедитесь, что система его «видит». Например, если вы собираетесь делать бэкап в файл, убедитесь, что каталог, где будет находится этот файл, создан. Ленточное устройство должно быть сконфигурировано на уровне ОС. Оно также должно поддерживаться ISM (список поддерживаемых устройств можно посмотреть в IBM Informix Storage Manager Administration Guide ). При конфигурировании устройства установите параметр no rewind. Для конфигурирования устройства из командной строки выполните команду: ism_add –device имя_устройства –type тип_устройства Замените имя_устройства полным путем к устройству (т.е. /dev/rmt/tape0 или /ifmx_data/backup_dir). Вместо тип_устройства укажите тип устройства, поддерживаемый ISM (4mm, 8mm, 5GB, dlt). Например, добавить ленточное устройство резервирования логических журналов можно такой командой: ism_add –device /dev/rmt/4_tape0 –type 4mm Статус устройств можно проверить командой ism_show –devices. Следующий шаг – установка устройства в ISM. Это делается с помощью утилиты nsradmin, которая должна быть запущена пользователем root. Запустите утилиту командой nsradmin –c. Выберите Select, а затем NSR device. Утилита выведет параметры первого сконфигурированного устройства. Текущие настройки устройства показаны в квадратных скобках ([]). Если необходимо что-то изменить, выберите команду Edit и выполните необходимые установки. Нанесение меток на тома (labeling volumes) После создания одного или нескольких устройств необходимо загрузить и промаркировать тома и объединить их в пул. Для дисковых устройств необходимо создать каталоги, для ленточных – вставить ленты. Процесс нанесения меток на новые тома идентичен повторному нанесению меток на существующие тома. Сначала необходимо решить, частью какого пула будет отдельный том. Выше мы уже говорили, что пул томов – это логическая группировка томов, содержащих один и тот же тип данных. Например, вы можете создать пул томов, содержащих бэкапы экземпляра, или пул томов, содержащих бэкапы логических журналов. После того, как том приписан к пулу, этот том будет монтироваться только при операциях именно с этим пулом. например, если все четыре устройства заняты лентами из пула бэкапов экземпляра, то в этом момент начинается бэкап логических журналов, то эта операция будет приостановлена до тех пор, пока в одно из устройств не будет вставлена лента из пула бэкапов логических журналов. В Таблице 7.4 приведены 9 основных пулов томов, конфигурируемых ISM

Таблица 7.4 Предопределенные пулы томов ISM

Категория пула томов

Описание

ISMData Эта категория предназначена для бэкапов экземпляра. В этот же пул пишутся бэкапы отдельных db-пространств. В этот пул входят два пула томов: ISMDiskData и ISMData. Первый предназначен для дисковых устройств, второй – для дисковых и ленточных устройств

ISMLogs Эта категория предназначена для бэкапа логических журналов. Содержит два пула – ISMDiskLogs для файловых устройств, ISMLogs – для файловых и ленточных устройств.

ISMDataClone Этот пул предназначен для создания копий пулов или сохраненных наборов ISMDiskData и ISMData

ISMLogsClone Этот пул предназначен для создания копий пулов ISMDiskLogs и ISMLogs

Default Является частью программы Networker. В обычных условиях этот пул не используется. Смотрите в разделе «Монтирование томов» предупреждение по этому поводу

Default Clone Является частью программы Networker. Этот пул поддерживает создание копий томов Default пула. В Informix не используется

Full Является частью программы Networker

Non Full Является частью программы Networker

Offsite Этот пул можно использовать для создания набора лент для хранения где-нибудь в другом месте

Нанесение метки на том выполняется утилитой ism_op. Синтаксис простой: ism_op –label имя_устройства –pool пул_томов –volume имя_тома Замените имя_устройства именем устройства (т.е. /opt/IBM/Informix/devices/tapes/tape0 или /ifmx_backups/dev_1). Замените пул_томов одним из предопределенных пулов ISM (Таблица 7.4), например, ISMData или ISMLogs. Замените имя_тома желаемым именем тома. Например, нанесем метку inst_tape_1 на ленту: ism_op –label /opt/IBM/Informix/devices/tapes/tape0 –pool ISMData \ –volume inst_tape_1 Нанесем метку на дисковый том, предназначенный для резервирования логических журналов: ism_op –label /ifmx_backups/dev_1 –pool ISMDiskLogs –volume danube_logs

Для установки recycle status созданных томов можно использовать утилиту ism_config. Для просмотра сконфигурированных томов можно использовать команду ism_show –volumes. Для удаления тома используется команда ism_rm –volume Монтирование томов Для того, чтобы ISM смог читать/писать маркированные тома, их сначала необходимо смонтировать в ISM. Монтирование – больше логический термин, хотя, конечно, перед началом монтирования ленту необходимо физически засунуть в стример. Перед попыткой смонтировать том выберите устройство и «определите том» (команда ism_op). ISM прочитает метку диска и обновит необходимые метаданные. Затем для монтирования/демонтирования тома выполните команду ism_op с необходимыми ключами Синтаксис операций ism_op достаточно прост: ism_op [-detect | -mount | -unmount] имя_устройства Замените имя_устройства именем устройства, на котором находится том. Например, определим и смонтируем том на ленте: ism_op –detect /opt/IBM/Informix/devices/tapes/tape0 ism_op –mount /opt/IBM/Informix/devices/tapes/tape0 При использовании ленточных устройств ISM не устанавливает блокировку на смонтированный том. Ничего не помешает вам вытащить из стримера смонтированный но неактивный том. Естественно, я рекомендую сначала отмонтировать том, а затем его вытаскивать. Если вы не отмонтируете том перед его выбросом из устройства, то всегда выполняйте обнаружение тома (ism_op -detect) перед использованием устройства. Операция обнаружения выполняет синхронизацию метаданных и «перезагружает» ленту. Поскольку устройства ISM относятся к не перематываемым, то без «перезагрузки» устройства может произойти следующая ситуация: ISM будет считать, что смонтирован том х, а лента находится в положение n, хотя в действительности лента уже практически закончилась. В результате том будет бесполезен. После того, как устройства сконфигурированы, на ленты нанесены метки , ленты приписаны к пулам томов и необходимая лента смонтирована, можно использовать ON-Bar для резервирования и восстановления экземпляров и логических журналов. Создание бэкапа средствами ON-Bar Выполнение бэкапа из командной строки имеет ряд преимуществ: во-первых, при наличии нескольких устройств можно распараллелить выполнение операции. Во-вторых, появляется возможность восстановления на заданный момент времени или до заданного журнала (the added flexibility of restoring to a logical log level or to the second in a moment-ni-time restore situation). Параллельный и последовательный бэкап несовместимы друг с другом. Поэтому при консольном использовании ON-Bar необходимо четко придерживаться одного формата бэкапа. Синтаксис параллельного бэкапа: onbar –b [-L уровень] [имя_пространства | имя_файла]

Параметр уровень может быть равен 0 (ноль), 1 или 2. Если он не указан, то создается бэкап 0-го уровня. По умолчанию выполняется бэкап всех пространств, но вы можете выполнить бэкап только необходимого пространства с помощью опции имя_пространства либо же указать полный путь к файлу, содержащему список пространств, которые необходимо забэкапить. В файле необходимо указать список пространств по одному в строке без знаков пунктуации. Последовательный бэкап выполняется командой: onbar –b –w [-L уровень] Этот тип бэкапа похож на резервирование средствами ontape, поэтому бэкап отдельного пространства или нескольких пространств не поддерживается. Параметр уровень может быть равен 0(ноль), 1 или 2. Если он не указан, то создается бэкап 0-го уровня. Есть еще одно отличие между параллельным и последовательным бэкапом. При параллельном бэкапе после завершения операции выполняется проверка метки тома и сохраненных наборов. Во время этой проверки экземпляр и db-пространства доступны конечным пользователям, то тома и устройства бэкапа – нет. Создание «fake»-бэкапа Как уже говорилось выше для выполнения некоторых задач администрирования необходимо выполнение бэкапа 0-го уровня. Среди этих задач – изменение режима журналирования баз, управление простыми BLOB-пространствами, повторное использование чанков, удаленных из db-пространства. Иногда создание такого бэкапа невозможно. В этом случае можно выполнить так называемый «fake»-бэкап: onbar –b –F Естественно, что из такого бэкапа ничего нельзя восстановить. «Fake»-бэкап можно использовать только для выполнения задач администрирования. Утилита ism_watch При использовании ISM можно отслеживать выполняемые им операции в реальном времени. Утилита ism_watch предназначена для мониторинга сообщений и активности сконфигурированных устройств и смонтированных томов. Инвентаризация томов Время от времени вам будет необходимо узнавать, какие сохраненные наборы находятся на определенном томе или истекли ли все сохраненные наборы на определенном томе. Некоторые данные можно извлечь из файла ixbar, но проще использовать утилиту ism_show. Сторонние системы управления лентами чаще всего тоже имеют подобные возможности. Синтаксис применения: ism_show –volume имя_тома Эта команда читает из каталога ISM данные по указанному тому. Восстановление из бэкапа ON-Bar Когда-то вам может потребоваться восстановить созданный бэкап. К счастью, восстановление бэкапов ON-Bar не является очень сложным делом. Вы можете выполнить восстановление одного или нескольких db-пространств (теплое восстановление) или восстановление всего экземпляра (холодное восстановление). Дополнительным преимуществом ON-Bar является возможность восстановления бэкапа с

достаточно большой гранулярностью. Например, вы можете остановить восстановление после наката транзакций определенного логического журнала. Возможно восстановление бэкапа по состоянию на определенное время с точностью до секунды. Восстановление экземпляров и /или db-пространств Выполнить восстановление бэкапа можно из программы с графическим интерфейсом или из командной строки. Вне зависимости от используемого интерфейса вы можете восстановить только сохраненные наборы, которые еще не истекли. Это приводит к необходимости регулярного создания бэкапов. Я рекомендую всегда иметь в наличии минимум два непросроченных сохраненных набора. Процесс восстановления можно мониторить просматривая файл BAR_ACT_LOG или, при использовании ISM, с помощью утилиты ism_watch. При необходимости вставить следующую ленту, в журнал будет выведено соответствующее сообщение. Как вы уже знаете, параллельный и последовательный метод бэкапа несовместимы между собой с точки зрения восстановления. Раньше эта разница возникала из-за разных методов обеспечения целостности при параллельном и при последовательном бэкапе. В IDS 11 и параллельный, и последовательный бэкап используют одну временную отметку, различие между ними состоит в том, что параллельный бэкап выполняется на несколько устройств. В результате, при восстановлении необходимо выбрать правильный формат команды. В таблице 7.5 и таблице 7.6 приведены самые часто используемые команды для параллельного и последовательного восстановления

Таблица 7.5 Синтаксис последовательного восстановления Команда восстановления ON-Bar

Описание

onbar –r -w Полное восстановление экземпляра (холодное восстановление) из последнего сохраненного набора. Для выполнения этой команды экземпляр должен находиться в состоянии офф-лайн. После завершения восстановления экземпляр будет находится в целостном состоянии.

onbar –r –w –p Физическое восстановление всех db-пространств без наката логических журналов. После завершения операции экземпляр находится в целостном состоянии, так как db-пространства восстанавливаются на момент начала операции бэкапа

onbar –r –w -l Выполняет накатку журналов на физически восстановленные db-пространства. После завершения восстановления экземпляр будет находится в целостном состоянии

onbar –r –w –t момент_времени

Выполняет полное восстановление на заданный момент времени. Момент времени задается в формате yyyy-mm-dd hh:mm:ss. После завершения операции экземпляр находится в целостном состоянии

onbar –r –w –n номер_журнала

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

Таблица 7.6. Синтаксис параллельного восстановления Команда восстановления ON-Bar

Описание

onbar -r Полное восстановление экземпляра (холодное восстановление) из последнего сохраненного набора. Для выполнения этой команды экземпляр должен находиться в состоянии офф-лайн. После завершения восстановления экземпляр будет находится в целостном состоянии.

onbar –r –p Физическое восстановление всех db-пространств без наката логических журналов. Начиная с IDS 11, после завершения операции экземпляр находится в целостном состоянии. В предыдущих версиях IDS экземпляр после завершения операции не был в логически целостном состоянии из-за того, что каждое db-пространство восстанавливалось по состоянию на свою собственную временную отметку о начале бэкапа. В результате для получения экземпляра в целостном состоянии было необходимо выполнять логическое восстановление.

onbar –r -l Выполняет накатку журналов на физически восстановленные db-пространства. После завершения восстановления экземпляр будет находится в целостном состоянии

onbar -r –p [пространство | -f имя_файла]

Теплое восстановление некритических db-пространств. Необходимые db-пространства можно указать непосредственно в командной строке через пробел или записать в файл. В файле db-пространства указываются по одному в строке

onbar –r –t момент_времени

Выполняет полное восстановление на заданный момент времени. Момент времени задается в формате yyyy-mm-dd hh:mm:ss. После завершения операции экземпляр находится в целостном состоянии

onbar –r –n номер_журнала

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

Оба типа восстановления поддерживают флаги модификации операции восстановления. В Таблице 7.7 приведены наиболее часто используемые. При параллельном и последовательном восстановлении вы можете перенаправить поток данных одного или нескольких пространств: rename [-f полное_имя_файла | -p исходный_путь \ -o исходное_смещение –n новый_путь –о новое_смещение] При выполнении операции восстановления все незаархивированные логические журналы будут скопированы на ленту. Это называется спасение (salvaging) логических журналов. Во время логического восстановления логические журналы будут перезаписаны

накатываемыми данными. Поэтому существующие журналы сначала сохраняются – вдруг они понадобятся для другой операции восстановления, например, на более позднее время. Поэтому первый шаг восстановления – монтирование тома из пула бэкапов логических журналов. Теплое восстановление из командной строки является двухшаговым процессом. Первый шаг – физическое восстановление: onbar –r [-w] –p –O [имя_пространств(а) | путь_к_файлу] Затем выполняется логическое восстановление: onbar –r –l Таблица 7.7 Дополнительные флаги восстановления

Флаг Описание

-О (заглавная буква «О»)

Применяется с любыми флагами, кроме –n и –l. Может применяться для нескольких целей:

Теплого восстановления db-пространств, находящихся он-лайн. Вы можете восстановить все db-пространства или использовать опции, описанные в Таблице 7.6, и передать команде список необходимых db-пространств. После завершения операции экземпляр будет находиться в логически целостном состоянии, поскольку во время проведения операции выполняется накатка логических журналов

Безусловного пересоздания несуществующего чанка. Вне зависимости от того, был ли оригинальный чанк создан на сыром устройстве или в файловой системе, чанк, создаваемый этой командой, будет располагаться в файле

Продолжения операции восстановления даже в том случае, когда в экземпляре нет критического db-пространства. В начале процесса восстановления проверяются все пути к чанкам. Иногда возникает ошибка невозможности записать по заданному пути или в заданное db-пространство. Этот флаг заставляет процесс восстановления продолжаться. Если пространство действительно недоступно, восстановление завершится ошибкой.

-restart Смотрите дальше раздел «Перезагружаемые восстановления» (restartable restores)

-e Выполняет внешнее восстановление. Внешние бэкап/восстановление выполняются при наличии централизованной фермы дисков (centralized disk farm environment) и используют возможности этой фермы поддерживать полностью синхронизированные копии дисков. Копии могут быть «разделены» (split off) или «заморожены» (frozen) путем приостановки работы экземпляра и выполнения разделения/заморозки. Таким образом копия будет содержать полный образ экземпляра на некоторый момент времени. при выполнении внешнего восстановления операции экземпляра приостанавливаются,

и выполняется восстановление дисков из их копии. Для синхронизации памяти экземпляра и метаданных экземпляра используется команда onbar –r [-w] -e

Если бэкап делался в последовательном режиме, не забудьте флаг –w. Во время восстановления восстанавливаемые пространства находятся в состоянии офф-лайн и недоступны пользователям. Во время теплого восстановления экземпляр находится в он-лайн и записывает необходимые данные в логические журналы, следовательно, процесс восстановления не может работать с этими журналами. В результате ядро СУБД создает структуры логического журнала во временных db-пространствах и записывает туда данные, необходимые для логического восстановления. Если во временных db-пространствах не будет достаточно места для хранения структур логических журналов, процесс восстановления завершится ошибкой. Хотя команде теплого восстановления вы можете передать время, на которое необходимо восстановиться: onbar –r –p –O danube_5 2008:01:04 23:45:31 , но этот флаг не будет иметь никакого эффекта. При логическом восстановлении все транзакции будут накачены и db-пространства будут находиться в том состоянии, в котором они были перед последней обработкой контрольной точки. Например, предположим, что в одном db-пространстве была родительская таблица для нескольких таблиц, расположенных в другом db-пространстве. Если вы хотите восстановить db-пространство родительской таблицы по состоянию на некоторое время, то можете оказаться в ситуации когда для строк дочерней таблицы нет соответствующих строк в родительской таблице. Если цель теплого восстановления – восстановиться на момент времени перед серьезной пользовательской или программной ошибкой, то лучше воспользоваться возможностью восстановления таблицы (table-level restore). Перезагружаемые восстановления (restartable restores) Одна из полезных возможностей ON-Bar – это возможность перезапуска процесса восстановления с того места, где он остановился по каким-либо причинам. Эта возможность существует благодаря БД-ориентированной реализации ON-Bar. Выше я уже упоминал, что в таблице bar_action хранятся данные об успехах/неуспехах каждой операции ON-Bar. При использовании флага –restart (onbar -restart) сервер использует эту таблицу для отслеживания ошибок восстановления отдельных объектов. Если операция восстановления объекта в БД завершилась ошибкой, будет запущен отдельный процесс восстановления именно этого объекта. Для использования перезагружаемого восстановления необходимо включить его: установить значение параметра RESTARTABLE_RESTORE в файле $ONCONFIG равным on. Изменение этого параметра требует перезапуска экземпляра. Параметр нельзя изменить перед попыткой выполнения перезагружаемого восстановления. Его необходимо установить перед начальной операцией восстановления (initial restore operation). Я рекомендую устанавливать RESTARTABLE_RESTORE перед инициализацией экземпляра. Расскажу о своем опыте использования перезагружаемого восстановления. Я установил параметр RESTARTABLE_RESTORE, убедился, что экземпляр запускался уже хотя бы один раз, а затем создал полный бэкап экземпляра. после завершения операции бэкапа я удалил одно из 6 db-пространств командой onspaces –d имя_db_пространства. Затем я восстановил бэкап на момент времени перед удалением db-пространства. Таким образом, я убедился, что могу восстановить все db-пространства.

После завершения восстановления и проверки логической целостности базы, я удалил не только db-пространство, но и файлы этого db-пространства в каталоге данных экземпляра. Затем я запустил восстановление экземпляра до того же момента времени, что и первую операцию восстановления. В файлах MSGPATH и BAR_ACT_LOG была зафиксирована ошибка, связанная с попыткой обращения к удаленным файлам db-пространства, но операция восстановления продолжалась. После завершения операции восстановления экземпляр находился в режиме быстрого восстановления. Я пересоздал файл для удаленного db-пространства, а затем выполнил команду onbar –restart. Удаленное db-пространство было восстановлено, были накачены журналы транзакций, и после завершения восстановления экземпляр находился в статическом режиме. Восстановление после катастрофического сбоя Как вы могли уже заметить, для корректного функционирования ON-Bar очень важны некоторые файлы и базы данных. В этом разделе я опишу эти структуры и расскажу, как их перестроить в случае катастрофического сбоя сервера. Во время инициализации экземпляра в корневом db-пространстве создается база данных sysutils. Она бэкапится всякий раз, когда выполняется бэкап корневого db-пространства. Зарегистрировавшись на сервере как пользовательinformix, вы можете сделать выгрузку этой базы в ASCII-файл с помощью утилиты dbexport. Восстановление этой БД возможно или через полное восстановление экземпляра, или путем выполнения команд SQL insert/update/delete, которые используют данные из текстовых файлов, созданных утилитой dbexport. Во время полного резервирования экземпляра файлы ixbar, $ONCONFIG НЕ резервируются. Эти два файла необходимо забэкапить на любое устройство и хранить вне серверной. Для восстановления достаточно просто скопировать файлы в каталог $INFORMIXDIR/etc. Данные загрузчика ISM (the ISM bootstrap information) резервируются во время бэкапа экземпляра. ISM создает и обслуживает каталог ISM. Он использует этот каталог для отслеживания месторасположения и статуса (viability) всех созданных сохраненных наборов. Без каталога ISM вы не сможете восстановить экземпляр. Восстановить этот каталог можно двумя способами: первый способ – просто пересоздать каталог. Второй метод ориентирован на восстановление информации о просроченных сохраненных наборах, с которых необходимо восстановиться. Оба эти метода требуют работы с консольными утилитами. Если каталог ISM поврежден или удален, вы можете восстановить его с сохраненного набора, созданного во время бэкапа экземпляра или db-пространства. Конечно, надо знать, какой сохраненный набор восстанавливать. В последних версиях ISM эти данные чаще всего хранятся в пуле Default. Если эта информация недоступна, то, чтобы найти самый свежий бэкап каталога ISM, придется просканировать все тома. После монитрования тома выполните такую команду: ism_catalog –find_bootstrap имя_устройства Эта команда выполняет сканирование тома и возвращает строку о последнем бэкапе каталога ISM, который хранится на этом томе. Зная том и номер сохраненного набора, выполните команду ism_catalog –recover. Команда восстановления сначала запросит имя устройства, на котором находится сохраненный набор. Затем будет запрошен номер сохраненного набора. Утилита также запросит номер начального файла и номер начальной записи (starting file number, starting

record number). Выберите 0 (ноль) в обеих случаях. После ввода необходимых данных и проверки, смонтирован ли том, с этого тома будет восстановлен каталог. Во время восстановления каталога восстанавливаются некоторые конфигурационные файлы ISM, в том числе файл nsr.res, содержащий множество конфигурационных значений. После восстановления каталога вы будете иметь доступ ко всем нестертым томам и непросроченным сохраненным наборам. Просроченные наборы можно восстановить если том, на котором они находятся, не достиг времени его очистки (the volume itself has not reached its recycle date). Естественно, что никакого физического восстановления в этом случае не происходит: просто обновляются необходимые записи в каталоге ISM. Для восстановления просроченных сохраненных наборов используется команда ism_catalog –recreate_from имя_устройства После выполнения этой команды статус тома будет изменен на disabled. Установка этого статуса предотвращает перезапись тома, но не предотвращает его очистку. Чтобы предотвратить очистку, установите ему с помощью команды ism_config очистку вручную (manual) Бэкап логических журналов с помощью ON-Bar Бэкап логических журналов с помощью ON-Bar несложен. Как уже говорилось во время обсуждения бэкапа и восстановления экземпляра или группы db-пространств, в IDS 11 логические журналы не являются строго необходимыми для восстановления экземпляра. Текущий логический журнал бэкапится во время бэкапа всего экземпляра. Такие бэкапы журналов не являются достаточными для восстановления системы при сбое. Для обеспечения возможности восстановления экземпляра журналы необходимо архивировать после их заполнения. Этот процесс обычно обслуживается так называемой программой тревоги (alarm program). Если в экземпляре происходит некоторое событие, например, заполнение логического журнала, СУБД вызывает программу или скрипт, имя которых указано в конфигурационном параметре ALARMPROGRAM (по умолчанию $INFORMIXDIR/etc/alarmprogram.sh), и передает им набор параметров. В скрипте по умолчанию есть параметр, который определяет, необходимо ли бэкапить заполненные журналы. Если этот параметр установлен, скрипт ALARMPROGRAM вызывает скрипт logs_full.sh (который тоже расположен в каталоге $INFORMIXDIR/etc). Для события «логические журналы заполнены» скрипт вызывает команду бэкапа журналов onbar –l (строчная буква L). От вас не требуется выполнять автоматический бэкап заполненных журналов. Вы можете бэкапить логические журналы из командной строки с помощью той же команды onbar –l Клонирование томов или сохраненных наборов При некоторых обстоятельствах бывает необходимо создавать копии томов или определенных сохраненных наборов. Такая практика называется клонированием тома или сохраненного набора. Клонирование томов и сохраненных наборов обеспечивает не только дополнительный уровень защиты от сбоев. Во время процесса клонирования выполняется проверка целостности сохраненных наборов. В случае обнаружения проблем с сохраненным набором или устройством хранения процесс клонирования проинформирует об этом администратора. Получив эти данные, вы сможете предпринять необходимые меры для создания новых целостных резервных копий. В следующем разделе мы рассмотрим еще одну программу проверки целостности сохраненных наборов. Для клонированных томов или сохраненных наборов в каталоге ISM создаются отдельные записи, просмотреть которые можно командой ism_show –volumes. Хотя клоны и являются отдельными

объектами, но они не полностью независимы от оригиналов. Клоны наследую от оригиналов период сохранения и статус переработки. Поэтому, если вам необходимо, не забудьте изменить период сохранения клона на manual. По умолчанию клонированные тома или сохраненные наборы нельзя использовать в операциях восстановления. При восстановлении ISM использует оригинальные том и сохраненный набор. Если вам необходимо использовать клон для восстановления, то перед началом операции восстановления необходимо выполнить одно из двух действий:

Удалить том

ism_op –volume имя_тома или

Изменить статус сохраненных наборов тома на expired

ism_config –volume имя_тома –disable_restore id_сохраненного_набора Когда начнется операция восстановления, ISM заменит, что оригинальные том или сохраненный набор недоступны, а доступны их клоны и затребует монтирование клонированного тома для восстановления данных с него. Для клонирования тома или группы сохраненных наборов необходимо иметь два устройства резервирования. На одном устройстве должен быть смонтирован том из пула ISMDataClone или ISMLogsClone, на втором устройстве – том, который необходимо клонировать. Для запуска операции клонирования выполните команду ism_clone. Клонирование может быть полезно еще в том случае, когда на сервере нет скоростных стримеров или для создания бэкапа выделяется очень маленький промежуток времени. в этом случае вы можете выполнить бэкап на дисковые тома. После создания бэкапа вы можете клонировать его на ленту. Проверка резервных копий утилитой Archecker В IDS 9.2 или IDS 9.3 в состав сервера вошла утилита, написанная Джоном Миллером для отдела технической поддержки. Называется она archecker и позволяет пользователям проверять резервные копии, созданные с помощью ON-Bar и ontape, без выполнения операции восстановления. Для управления операциями archecker можно использовать управляющий файл. Скопируйте шаблон ac_config.std, расположенный в каталоге $INFORMIXDIR/etc, и отредактируйте его. Установите переменную окружения AC_CONFIG так, чтобы она указывала на новое имя файла или его месторасположение. В приведенном шаблоне установлены три параметра, одним из которых является путь к журналу работы утилиты, но вы можете установить 8 других параметров, включая размер блока ленты, расположение файла IXBAR, используемое ленточное устройство, значение таймаута, путь в файловой системе, где archecker будет хранить необходимые структуры данных. После настройки конфигурационных файлов запустить archecker можно двумя путями. Из командной строки указав имя путь к бэкапу ontape или ON-Bar, или через ON-Bar API для проверки последнего бэкапа ON-Bar. Утилита проверяет таблицы системных БД, расположенных в корневом db-пространстве, а затем – контрольные структуры db-пространств. Если в db-пространстве расположена пользовательская БД, archecker проверяет контрольные таблицы базы данных. После этого утилита проверяет поток данных db-пространства. Синтаксис вызова простой:

archecker –b (для ON-Bar) archecker –t (для ontape) Флаг –v предназначен для более подробного вывода данных, хотя он немного меняет работу утилиты, поэтому желательно использовать параметр AC_VERBOSE в конфигурационном файле. Флаг –s предназначен для копирования вывода в журнал archecker на экран. Если вы используете «проверочную» опцию ON-Bar, то ON-Bar прямо вызывает утилиту archecker. Кроме вывода в журнал archecker данные также записываются в BAR_ACT_LOG. Использование интерфейса ON-Bar к утилите предоставляет дополнительные опции, которые недоступны из командной строки. Используя логические журналы вы можете выполнить проверку до определенного момента времени как и указать проверяемые db-пространства. Синтаксис использования: onbar -v [-t временная_отметка] [-w] [-f имя_файла | список_db_пространств] Флаг –w указывает «всю систему» или последовательные бэкапы ON-Bar. Вы можете вручную указать проверяемые db-пространства или указать файл с их списком после флага –f. Использование восстановления на уровне таблиц (table-level restore) В IDS 10 к утилите archecker была добавлена давно ожидавшаяся администраторами возможность. Эта возможность называется восстановление на уровне таблиц (table-level restore TLR) и предоставляет возможность выполнить восстановление отдельной таблицы, а не целого экземпляра (как ontape или ON-Bar) или одного или нескольких db-пространств (как ON-Bar). В ранних версиях неумышленное или умышленное повреждение данных приводило к необходимости выполнения сложной работы по спасению неповрежденных данных. Администратору было необходимо выполнить бэкап экземпляра, затем восстановить экземпляр или пространство из предыдущего бэкапа до момента времени перед повреждением данных, перекопировать данные из таблиц(ы) в другие db-пространства, восстановить экземпляр в most current state, а затем заменить поврежденные данные данными из раннего бэкапа. С помощью новой функциональности archecker вы можете восстанавливать данные без перевода db-пространств в офф-лайн. Ниже мы обсудим управляющий файл, который позволяет указывать параметры восстановления. Одна из самых полезных возможностей – восстановление бэкапа, созданного на физическом сервере с одной ОС, на физический сервер с другой ОС. Можно выполнять миграцию баз данных между разными окружениями без необходимости привлечения пары dbexport/dbimport. Можно извлекать данные из одного бэкапа и, с помощью распределенной транзакции, пересылать их другому экземпляру по сети. TLR может работать в двух режимах – физическом и логическом. При работе в физическом режиме используется бэкап 0-го уровня, созданный средствами ontape или ON-Bar. Из этого бэкапа извлекаются данные, удовлетворяющие условиям, заданным в контрольном файле. Если таблица распределена по нескольким db-пространствам и бэкап был создан средствами ON-Bar в параллельном режиме, то можно выполнить и операции TLR в несколько потоков (для каждого потока используется свой конфигурационный файл). При работе в логическом режиме после обработки архива 0-го уровня просматриваются логические журналы, и в них выполняется поиск транзакций, выполнявшихся на целевой таблице. Вы можете указать выполнять ли только поиск транзакций или выполнять и поиск, и накат таких транзакций. По умолчанию если данные

удовлетворяют условиям, заданным в контрольном файле, данные из журнала переносятся во временную таблицу, откуда они потом накатываются на целевую таблицу. С помощью такого подхода вы можете восстановить целевую таблицу на момент времени перед ее повреждением. В этом режиме не поддерживаются параллельные операции. А что делать, если вы не знаете, когда критически важная таблица была удалена из базы? Не беспокойтесь. При обработке записей логического журнала для определенной таблицы команда drop table игнорируется. Операции TLR контролируются с помощью командного файла схемы (schema command file). В этом файле с помощью простых команд SQL задаются исходная и целевая базы(а), таблицы(а), схема таблиц(ы), время, по состоянию на которое необходимо восстановить данные и прочие параметры. Полный путь к файлу можно задать с помощью параметра AC_CONFIG либо передать как аргументы утилите archecker. В контрольном файле используются 5 основных команд SQL: database, create table, insert into, restore, set. Через выражение insert into поддерживаются также команды select, insert. Структура файла очень проста. Сначала вы открываете базу данных. Затем определяете схему исходной таблицы(таблиц), откуда будут извлекаться данные. Также необходимо определить целевую таблицу(ы). Схема целевой таблицы не должна обязательно совпадать со схемой исходной – эти таблицы могут отличаться в терминах количества столбцов, имен столбцов, схемы фрагментирования. Типы данных в столбцах должны быть совместимы друг с другом (например, данные smallint можно загрузить в столбец int). С помощью ключевого слова restore вы можете указать режим выполнения TLR-операции – физический или логический, а также время, по состоянию на которое необходимо выполнить восстановление. Ключевое слово set позволяет указать количество транзакций или количество строк, которые необходимо обработать перед выполнением commit work. Такой подход уберегает вас от возникновения длинной транзакции. Можно указать db-пространства, используемые для хранения временных таблиц, в которые записываются данные из журнала транзакций во время работы утилиты в логическом режиме. Эти таблицы не могут быть созданы во временных db-пространствах экземпляра. Давайте рассмотрим пример командного файла (Листинг 7.1) database stores; create table my_source_table (customer_num serial, fname char(15), lname char(15), company char(20), address1 char(20), address2 char(20), city char(15), state char(2), zipcode char(5), phone char(18) ) fragment by expression (customer_num<114) in data_space_1, (customer_num>=114) in data_space_2;

create table mytest (customer_num serial, fname char(15), lname char(15), company char(20), address1 char(20), address2 char(20), city char(15), state char(2), zipcode char(5), phone char(18) ) in data_space_12; insert into mytest select * from my_source_table; Листинг 7.1. Пример контрольного файла TLR В этом базовом примере необходимо обратить внимание на несколько вещей:

Определение исходной таблицы вполне ясно. В нем указываются имена и типы данных столбцов и схема фрагментирования (если есть), ограничения, ключи, индексы не указываются.

Если целевая таблица не существует в базе данных, то она также должна быть полностью описана. В этом примере имена столбцов обеих таблиц идентичны, но этого не требуется. Если целевая таблица существует в БД, можно сразу переходить к команде insert.

Поскольку в командном файле больше ничего не указано, утилита archecker будет работать в логическом режиме и выполнять восстановление до ближайшего возможного момента времени.

Если вам необходимо восстановить одну или несколько удаленных таблиц, то в контрольном файле необходимо указать только удаленные таблицы. В Листинге 7.2 приведена иллюстрация этого сценария database stores; create table my_source_table (customer_no serial, fname char(15), lname char(15), company char(20), address1 char(20), address2 char(20), city char(15), state char(2), zipcode char(5), phone char(18) ) fragment by expression (customer_num<114) in data_space_1, (customer_num>=114) in data_space_2; insert into my_source_table select * from my_source_table;

set workspace to work_1,work_2; Листинг 7.2. Контрольный файл TLR для восстановления удаленной таблицы В этом случае оригинальная таблица будет пересоздана. Поскольку команда выполняется в логическом режиме, на таблицу будет выполнен накат записей логического журнала, но команда drop table будет проигнорирована. В контрольном файле также указано, что временные таблицы, в которые помещаются записи, сгенерированные утилитой archecker при обработке забэкапленных объектов, размещаются в db-пространствах work_1 и work_2. Мы рассмотрели примеры обработки одной таблицы, но archecker может извлекать данные из нескольких таблиц и записывать данные в несколько таблиц. В примере из Листинга 7.3 для заполнения целевой таблицы используются две исходные таблицы. В Листинге 7.4 – наоборот. Для уменьшения размера листингов в примерах не показано, что схемы таблиц должны быть одинаковы (одинаковое количество столбцов и тип данных в столбцах ). В противном случае вставка данных завершится ошибкой. database stores; create table my_source_table_1 (columns) in data_space_2; create table my_source_table_2 (columns) in data_space_6; create table my_target_table (columns) in data_space_12; insert into my_target_table select * from my_source_table_1 , my_source_table_2; set workspace to work_1,work_2; Листинг 7.3. Контрольный файл TLR для восстановления одной таблицы с использованием нескольких исходных таблиц database stores; create table my_source_table (columns) in data_space_2; create table my_target_table_1 (columns) in data_space_12; create table my_target_table_2 (columns) in data_space_13; insert into my_target_table_1 select col_1, col_2, col_3 from my_source_table; insert into my_target_table_2 select col_4, col_5, col_6 from my_source_table; set workspace to work_1, work_2;

Листинг 7.4. Контрольный файл TLR для восстановления нескольких таблиц из одной исходной. В Листинге 7.5 приведен пример, в котором используются все возможности database mac_stores; create table mac_customer (customer_num serial, fname char(15), lname char(15), company char(20), address1 char(20), address2 char(20), city char(15), state char(2), zipcode char(5), phone char(18) ) in data_space_9; database hpux_stores; create table mac_customer (customer_num serial, fname char(15), lname char(15), company char(20), address1 char(20), address2 char(20), city char(15), state char(2), zipcode char(5), phone char(18) ) in data_space_8; insert into mac_stores@mac_instance.mac_customer select * from my_customer where zipcode matches “75*”; restore to ‘2008-03-08 21:23:02’; set workspace to work_1, work_2; Листинг 7.5. Распределенная операция TLR В примере осуществляется распределенная операция TLR, когда бэкап, созданный на сервере под управлением HP-Unix, разворачивается на сервере Macintosh. При написании условий фильтрации вы можете использовать все базовые условия, доступные в SQL: =, <=, and, or, is[not] null и т.д. Нельзя использовать UDR, триггеры, представления, подзапросы и другие подобные возможности SQL.

Синтаксис использования TLR: archecker [-b | -t] –X [-f путь_к_файлу] [-v] [-s] \ [-l phys | stage | apply] Ключ –b указывается в том случае, когда бэкап был сделан средствами ON-Bar, ключ –t – если бэкап выполнялся при помощи ontape. Флаг –f применяется в том случае, если полный путь к контрольному файлу не был указан в параметре AC_CONFIG. Флаги –v, -s определяют вывод подробной информации и перенаправление вывода утилиты на экран. Флаг –l (строчная буква L) предназначен для указания режима работы TLR – физический или логический режим работы. Как я говорил выше, по умолчанию выполняются все три стадии, но при необходимости вы можете выполнить одну или две, например, -l phys, stage. В этом примере, данные будут извлечены и помещены во временные таблицы. Заключение С появлением в составе Informix Dynamic Server комплекта утилит ON-Bar, вы можете более гибко настраивать политику резервного копирования и восстановления. Но не надо забывать о возможности работы и с ontape. Эти две программы позволяют вам резервировать экземпляр (с помощью ON-Bar можно резервировать группы db-пространств). С помощью команд SQL или утилит IDS (onunload) можно выполнять резервное копирование таблиц. Проверять резервные копии можно с помощью утилиты archecker, также она может быть использована для восстановления одной или нескольких таблиц из бэкапа без необходимости переводить экземпляр или db-пространства в состояние офф-лайн. При разработке стратегии резервного копирования и восстановления примите во внимание следующее:

вне зависимости от размера экземпляра и используемой стратегии резервирования периодически необходимо выполнять полный бэкап экземпляра. период времени между такими бэкапами зависит от:

размера экземпляра времени, необходимого для создания бэкапа количества изменений в экземпляре допустимого времени на восстановление

начиная с IDS 11 утилитами ontape и ON-Bar официально поддерживаются

бэкапы со сжатием. Начиная с этой версии поток данных, передаваемый API бэкапа/восстановления, можно сжимать и шифровать. В ISM включена возможность сжатия данных, задействовать ее можно установив переменную окружения ISM_COMPRESSION. ISM использует программный алгоритм сжатия, более целесообразным может быть использование аппаратного сжатия вашего устройства резервного копирования.

При использовании утилиты ontape, если параметры TAPEDEV и/или LTAPEDEV указывают на ленточные устройства, установите параметры TAPESIZE и LTAPESIZE равными 0 (ноль). В этом случае может быть использована вся емкость ленты. Ontape корректно обрабатывает события достижения конца ленты. Установка максимального размера файла в качестве значения этого параметра применяется в том случае, когда TAPEDEV и/или LTAPEDEV указывают на дисковые файлы или на каталог.

Если в качестве устройства бэкапа для ontape вы указываете /dev/null, вы можете быстро выполнить изменение режима журналирования базы, очистку логических журналов. Естественно, восстановить такой бэкап нельзя. Использование /dev/null

в качестве устройства бэкапа не имеет большого смысла в связи с наличием возможности выполнения «fake»-бэкапа. Установка параметра LTAPEDEV равным /dev/null отменяет возможность использования ON-Bar для выполнения резервного копирования и восстановления. Для полного распараллеленного восстановления экземпляра логические журналы не нужны, они нужны для восстановления на определенный момент времени, для частичного восстановления, когда для обеспечения целостности необходимо выполнить операцию накатки записей логического журнала.

Вне зависимости от используемых для бэкапа утилит, возможность создания бэкапов разного уровня сокращает количество времени, необходимое для выполнения резервного копирования.

Если базы данных экземпляра являются журанлируемыми, и в системе доступны только ленточные устройства, убедитесь, что вы выполняете резервное копирование в то время, когда оно может выполниться без заполнения логических журналов.

Некоторые операции DML и DDL (удаление BLOB, создание BLOB-пространства) для своего завершения требуют закрытия и бэкапа логического журнала, в котором фиксируется транзакция этой операции. Утилиты ontape и ON-Bar имеют флаги, позволяющие выполнить закрытие и резервное копирование текущего журнала.

ON-Bar может использоваться в параллельном и последовательном режиме. Если доступно несколько устройств резервного копирования, то с помощью параллельного резервного копирования вы можете существенно уменьшить время выполнения операции. Выполнение параллельного восстановления средствами ON-Bar больше не требует для обеспечения логической целостности накатки логических журналов.

Конфигурационные файлы ISM и экземпляра могут быть забэкаплены на устройство небольшой емкости или просто распечатаны. Резервные копии этих файлов существенно помогут вам в том случае, когда нужно выполнить восстановление системы после катастрофического сбоя (т.е. когда нужно восстановить не только базы данных, но и сам сервер БД).

Вы можете выполнить клонирование томов или сохраненных наборов ON-Bar. Это может быть необходимо для создания удаленных окружений (remote environments), проверки целостности томов или сохраненных наборов. Клонированные тома и сохраненные наборы наследуют параметры своих оригиналов. Клоны не могут быть использованы для восстановления, если вы не удалите записи об оригиналах из каталога ISM.

Время от времени следует проверять целостность резервных копий с помощью утилиты archecker.

В следующем разделе мы рассмотрим различные утилиты, позволяющие заглянуть в экземпляр или в сессию пользователя.

Часть 8. Мониторинг экземпляра В этой части:

Определение SQL-запроса, который выполняется сессией пользователя Насколько эффективно экземпляр читает и записывает данные Сколько пересечений имеет таблица Проверка целостности индекса Экземпляр в режиме он-лайн – с какими значениями параметров он туда перешел Мониторинг экземпляра в реальном времени с помощью графических утилит

Как вы знаете, высокопроизводительные окружения БД – это не «plug-and-play». В сложных окружениях сервера БД нуждаются в мониторинге и обслуживании. Хотя потенциально Informix может работать и без обслуживания (главное, чтобы бэкапы делались), но бывают такие случаи, когда необходимо узнать, что же, все-таки, происходит в внутри экземпляра или базы данных. В этой части я расскажу об утилитах, которые могут помочь выполнить такую работу. Две из них работают из командной строки и являются основными средствами мониторинга. После прочтения раздела вы будете знать, как использовать эти утилиты. Новый интерфейс системного администрирования Начинающие администраторы часто жалуются на трудности в понимании консольных утилит IDS. Поскольку IDS изначально разрабатывался под UNIX, то его интерфейсом мониторинга и управления были консольные утилиты. Есть и графические средства администрирования – OAT, Server Studio, DBSonar. В IDS 11 был представлен новый интерфейс администрирования, который не требует ни GUI, ни запоминания параметров вызова onspaces, onparams: SQL-ориентированное API администрирования. Оно создано на основе системной БД sysadmin и 16 новых таблиц в БД sysmaster и позволяет членам группы DBSA (Database Server Administrator) получить доступ к широкому спектру возможностей по управлению сервером (мониторинг производительности, операции обслуживания). Вы можете выполнять операции администрирования с любого компьютера, который может подключиться к экземпляру. API предлагает набор функций для выполнения ежедневных задач администрирования: управления пространствами хранения, конфигурирования экземпляра. Функция task() в качестве параметра принимает строку, описывающую выполняемую операцию, и набор параметров этой операции. Она возвращает текстовое сообщение, говорящее об успешности или неуспешности выполнения операции. Например, execute function task (‘add log’, ‘logs_space’, ‘10MB’, ‘1’); created logical log number 15 in logs_space execute function task (archive fake’); backup complete Функция admin() принимает такой же набор параметров, но возвращает целое число, которое сообщает о статусе выполнения команды – успешно или нет. Если возвращается положительное число, то команда успешно выполнена, а это положительное число представляет собой номер строки в таблице command_history, куда записана транзакция. Если возвращено значение 0 (ноль), то команда выполнена успешно, но сервер не может

вставить запись в таблицу истории (необходимо проверить доступное свободное место). Если возвращается отрицательное число, то команда не выполнена. Например, execute function admin(‘create with_check dbspace’, ‘tagus_data_1’, ‘/opt/IBM/Informix/devices/tagus/data_1’, ‘300 MB’, ‘0’); 234 execute function admin(‘shutdown’); 400 При использовании этого API пути к файлам могут начинаться с переменной окружения, установленной на целевом сервере. Для указания размеров вы можете использовать реальные единицы (KB, MB, GB) вместо страниц или килобайт (этого иногда требуют консольные утилиты). С помощью SQL API вы можете выполнить порядка 80 задач. В документе IBM Informix Guide to SQL: Syntax раздел 6 посвящен именно SQL API. Утилиты командной строки Каждый порт Informix Dynamic Server содержит в своем составе утилиты onstat и oncheck. Они являются «lingua franca» средств мониторинга Informix. На протяжении разработки IDS в состав этих утилит были добавлены новые флаги, позволяющие получать разнообразные данные по вопросам функционирования экземпляра и БД.

С помощью утилиты onstat вы можете отслеживать «статусы» экземпляра или потока. Выходные данные получаются путем выполнения запросов к интерфейсу мониторинга системы (system monitoring interface SMI). Вывод onstat представляет собой мгновенное значение, поэтому результаты работы этой утилиты могут сильно отличаться во времени. Утилита oncheck используется для проверки экземпляра или базы данных. Эти утилиты и используемые ими флаги неплохо описаны в IBM Informix Dynamic Server Administrator’s Reference. В этом разделе я не буду пояснять каждый флаг, а вместо этого постараюсь более подробно рассказать о флагах, которые я считаю наиболее полезными. Некоторые команды, например, onstat –p, были описаны в других частях книги, поэтому здесь мы к ним возвращаться не будем. Утилита onstat Для новичков в Informix утилита onstat является одной из самых сложных. Ее сложность состоит в большом количестве доступных флагов. После некоторых флагов требуется указать только одну букву в верхнем или нижнем регистре, после флага –g необходимо указывать трехбуквенное сокращение и иногда дополнительные параметры. В Листинге 8.1 приведен список ключей утилиты Использование onstat[-abBcCdDfFgGhjklmOpPRstTuxXz] [-I] [-r [<секунд>] ] [-o [<выходной файл>] ] [<входной файл>]

Флаг

Описание

-- Справка об использовании команды

<входной файл>

Чтение информации о разделяемой памяти из определенного файла дампа

-а Выводить всю информацию

-b Выводить буферы

-В Выводить все буферы

-с Вывести конфигурационный файл

-С Вывести запросы чистильщика btree

-d [update] Вывести пространства и чанки update -обновить статистику BLOB-чанков

-D Вывести данные о пространствах и детальную статистику чанков

-f Вывести статус dataskip (print dataskip status)

-F Распечатать данные о чистильщиках страниц (page flushers)

-g <команда> Многопоточная команда или команда Enterprise replication (см. ниже)

-G Вывести идентификаторы глобальной транзакции (global transaction IDs)

-h Вывести данные о цепочке буферного хэша (buffer hash chain info)

-i Интерактивный режим

-j Вывести интерактивный статус активного процесса onpload

-k Распечатать блокировки

-l Вывести данные о журналировании (print logging)

-m Вывести журнал событий (message log)

-o <имя файла> Вывести содержимое разделяемой памяти в указанный файл (по умолчанию, файл onstat.out)

-O Вывести данные о памяти оптической подсистемы и кэше (optical subsystem memory and staging cache information)

-p Распечатать профайл

-Р Print partition buffer summary

-r <секунд>

Обновлять данные каждые <секунд> секунд (по умолчанию 5)

-R Вывести LRU запросы

-s Вывести данные о защелках (latches)

-t Вывести табличные пространства (tablespaces)

-T Вывести информацию о табличных пространствах

-u Вывести пользовательские сессии

-х Вывести транзакции

-Х Вывести список разделяющих и ожидающих буферов (entire list of sharers and waiters for buffers)

-z Zero profile counts

Многопоточные команды Флаг Описание

act Вывести активные потоки

afr <имя_пула | ид_сессии> Распечатать выделенные фрагменты пула

all Распечатать все многопоточные данные

ath Распечатать все потоки

buf Распечатать информацию из профайла, относящуюся к буферным пулам

ckp Вывести статистику контрольной точки (checkpoint statistics)

cmsm Вывести статистику Connection Manager

con Print conditions with waiters

cpu Вывести информацию по ЦПУ для всех потоков

dbc Вывести информацию о потоке dbScheduler/dbWorker

ddr Вывести информацию о постобработке журнала DDR (print DDR log post processing information)

dic Вывести данные словарного кэша (dictionary cache)

dis Вывести список серверов БД и статус каждого из них

dll

Вывести статистику динамической библиотеки

dmp <адрес> <длина> Выполнить дамп <длина> байтов разделяемой памяти, начиная с <адрес>

dri Вывести информацию репликации данных

dsc Вывести список информации распределенного кэша (print a list of distributed cache information)

env [all | <ид_сессии>] ] [<имя_переменной>[,<имя_переменной>]]

Показать переменные окружения

ffr <имя_пула | ид_сессии> Распечатать фрагменты свободного пула

glo Распечатать глобальную многопоточную информацию

his [<ntraces>] Вывести информацию трассировки SQL-запроса для <ntraces> Без <ntraces> - вывести все из буфера трассировки

idxscans Распечатать профайлы сканирования индекса

imc Распечатать информацию о подключенных экземплярах MaxConnect

iob Распечатать использование большого буфера ВП ввода/вывода

iof Распечатать статистику дискового ввода/вывода по чанку/файлу

iog Распечатать глобальную информацию AIO

iov Распечатать статистику дискового ввода/вывода по ВП

ipl Распечатать статус журналирования индексной страницы (index page logging status)

lap Вывести информацию light append

lmx Распечатать все блокированные мьютексы

lsc Распечатать информацию light scan

mem [<имя_пула> | <ид_сессии>] Распечатать статистику пула

mgm Распечатать информацию менеджера выделения памяти (Memory Grant Manager)

nbm

Распечатать карту блока нерезидентных сегментов

nsc [идентификатор_клиента] Распечатать статус сетевой разделяемой памяти?? (net shared memory)

nsd Распечатать данные сетевой разделяемой памяти (net shared memory)

nss [идентификатор_сесии] Распечатать статус сетевой разделяемой памяти?? (net shared memory)

ntd Распечатать информацию диспетчера сети (net dispatch)

ntm Распечатать информацию сетевого сообщения (net message)

ntt Распечатать времена доступа потока сетевого пользователя ( net user thread access times)

ntu Распечатать информацию профайла потока сетевого пользователя (net user thread profile information)

opn [<tid>] Распечатать открытые таблицы

plk Распечатать профайлы блокировок раздела (partition lock profiles)

pos Распечатать файл /INFORMIXDIR/etc/.infos.DBSERVERNAME

ppf [<номер_раздела> | 0] Распечатать профайлы раздела (print partition profiles)

prс Распечатать информацию о кэше SPL-процедуры

qst Распечатать статистику запроса

rbm Распечатать карту блока резидентного сегмента

rea Распечатать готовые потоки (ready threads)

rss [verbose | log | <имя_RSS_сервера>] Распечатать информацию об RSS-сервере

rwm Распечатать списки мутексов чтения/записи

sch Распечатать статистику планировщика ВП

sds [verbose | <имя_SDS_сервера>] Распечатать информацию по SDS

seg Распечатать статистику сегментов памяти

ses [<идентификатор_сесии>]

Распечатать информацию о сессии

sle Распечатать все спящие потоки

smb Вывести использование больших смарт объектов

smx [ses] Распечатать информацию о мультиплексоре сервера

spi Распечатать спин-блокировки с длительными спинами (spin locks with long spins)

sql [<идентификатор_сесии>] Распечатать информацию об SQL-запросе

srс <паттерн> <маска> Выполняет поиск <паттерн> в памяти, где <паттерн>==(память & <маска>)

ssc [pool | all] Распечатать итоговые данные по пулу кэша SQL-запроса или итоговые данные по пулу кэша SQL-запроса и его содержимое (all) (SQL statement cache pool summary or SQL statement cache summary and entries including key-only entries)

stk <tid> Дамп стека определенного потока

stm [<идентификатор_сессии>] Распечатать примерное использование памяти всеми подготовленными запросами сессии

stq [<идентификатор_сессии>] Распечатать информацию потока запроса (stream queue information)

sts Распечатать максимальный и текущий размер стека

tgp Print generic page thread profiles

tpf [<tid> | 0] Распечать профайлы потока

ufr [<имя_пула | идентификатор_сессии>] Pool usage breakdown

vpcache Распечатать статистику кеша блока памяти ЦПУ ВП (CPU VP memory block cache statistics)

wai Распечатать ждущие потоки

wmx Распечатать вес мутексы с ждущими их объектами (all mutexes with waiters)

wst Распечатать статистику ожидания потока

Команды Enterprise Replication (ER) cat [scope | replname] Распечатать информацию глобального

каталога Enterprise Replication cdr Распечатать статистику ER

cdr config [имя_параметра] [long] cdr config CDR_ENV [имя_переменной] [long]

Распечатать конфигурационные данные ER. Если не указывать параметр, будет выведено имя и информация всех возможных параметров

dtc Распечатать статистику ER delete table cleaner

dss [UDR | UDRx] Распечатать статистику о потоках синхронизации данных и определенных пользователем типах данных

grp [A|E|Ex|G|L|Lx|M|Mz|P|pager|R|S|Sl|Sx|T |UDR|UDRx]

Распечатать статистику ER grouper

nif [all | sites | serverid | sum] Распечатать статистику сетевого интерфейса ER

que Распечатать статистику очередей высокого уровня ER (ER high-level queues)

rcv [serverid] Распечатать статистику менеджера приема ER (ER receive manager)

rep [replname] Распечатать события, стоящие в очереди менеджера-планировщика (events that are in the queue for the schedule manager)

rqm [ACKQ | CNTRLQ | RECVQ | SENDQ | SYNCQ | SBSPACES | FULL | BRIEF | VERBOSE]

Распечатать статистику очередей низкого уровня ER (ER low-level queues)

sync Распечатать статус синхронизации ER Листинг 8.1 флаги и параметры утилиты onstat

Функциональность утилиты onstat дает вам возможность мониторинга экземпляра по многим параметрам. Такие возможности много лет существуют для мейнфреймов, но их практически нет для серверов на обычных компьютерных платформах. Функционал утилиты onstat позволяет видеть, что происходит в экземпляре в любой момент времени. Какие-то данные, выводимые onstat, могут показаться сложным шифром, поскольку выводятся они в 16-ричной форме. Для получения информации о происходящем вам может потребоваться проанализировать вывод onstat с разными ключами. У onstat есть очень полезный ключ –i : работа в интерактивном режиме, при работе в в котором вы можете указывать необходимые флаги и ключи. Обратите внимание, что флаги, указанные строчными и прописными буквами выводят разные данные. Поскольку утилита подключена к разделяемой памяти сервера, ответ на запросы будет практически мгновенным. В этом режиме работы доступны все ключи onstat, включая ключ –r секунд, который предписывает повторять команду каждые n секунд. В интерактивном режиме доступен флаг –rz секунд, который предписывает не только повторять команду каждые n секунд, но и сбрасывать статистические счетчики перед каждой итерацией. Повторяющееся выполнение команды обычно используется для мониторинга использования ресурсов во время выполнения какой-нибудь операции. Для прерывания выполнения повторяющейся команды нажмите Ctrl+C. Для выхода из интерактивного режима нажмите Ctrl+D

Просмотр пользовательских потоков Одна из самых обычных задач – определение того, что делает пользовательский поток и какие ресурсы он использует. Просмотреть активные сессии и их потоки можно с помощью команды onstat –u. В третьем столбце вывода этой команды представлен идентификатор сессии (sessid), который может быть использован для получения детальных данных об этой сессии и ее потоках. Получение таких данных требует использования флага –g с дополнительными параметрами. Если нам необходима информация о сессии, мы используем флаг –g ses sessid, где sessid – идентификатор соответствующей сессии. Например, если мы хотим узнать, что делает пользователь carlton в сессии 220, то выполняем команду onstat –g ses 220. Часто вас будет интересовать не подробный отчет о сессии, а только, какой эта сессия выполняет SQL-запрос. Например, это интересно знать, когда сессия выполняет много операций записи и чтения или внезапно умирает. В этом случае используется флаг –g sql sessid. Результат вывода представляет собой информацию, относящуюся к SQL-запросу, выполняемому сессией. Зная из вывода команды onstat -u идентификатор сессии и адрес разделяемой памяти, вы можете отслеживать блокировки (-k), защелки (-s), транзакции (-x), использование буфера (-X), активные, готовые и ждущие потоки (-g act, -g rea, -g wai) и другие данные по интересующей вас сессии. Информация о дисках и чанках Команда onstat –d используется для просмотра дисковой конфигурации экземпляра. она не предоставляет данных о распределении дискового ввода/вывода экземпляра. такие данные можно получить с помощью указания других флагов утилиты onstat. Первый – это onstat –D. Эта команда во многом похожа на onstat –d, но еще показывает чтения со страниц (pages Rd) и записи на страницы (pages Wr) на уровне чанка. Эта информация полезна, если db-пространство состоит не из одного чанка. При необходимости вы можете сбросить статистические счетчики, используемые этой командой, с помощью onstat –z. Вторая команда мониторинга дискового ввода/вывода onstat –g iof. Она показывает общую статистику ввода/вывода, а не статистику прочитанных и записанных страниц. В IDS эта команда выводит дополнительные данные, включая среднее время ввода/вывода, количество операций ввода/вывода за секунду и т.д. С помощью команды onstat –g iov вы можете отслеживать нагрузку виртуальных процессоров ввода/вывода и при необходимости добавлять или удалять такие процессоры. Может быть полезна команда onstat –C. Вывод этой команды показывает number of backlogged index deletions (хрен его знает, что такое. В большой таблице описано как запросы чистильщика btree). Общий мониторинг экземпляра К сожалению, нельзя дать четкий алгоритм общего мониторинга экземпляра, т.е. нельзя сказать «очень важны флаги 1, 2 ,17, а другие не так необходимы и важны». В разных ситуациях вам понадобятся разные возможности утилиты onstat. Я опишу команды, которые, по моему мнению, важны и должны использоваться регулярно. Первая команда onstat –g seg выводит статистику разделяемой памяти. Она показывает оба сегмента разделяемой памяти (резидентный и виртуальный), размер каждого сегмента и количество свободных блоков в каждом сегменте. Вам необходимо мониторить количество сегментов виртуальной разделяемой памяти. Виртуальная память используется пользовательскими потоками и эффективность ее использования снижается с каждым новым выделенным блоком. Если во время нормальной работы системы вы видите два или более сегмента виртуальной памяти, попробуйте их объединить командой onmode –F . Если это не поможет освободить дополнительные сегменты(сегмент), то во время периода обслуживания увеличьте значение конфигурационного параметра SHMVIRTSIZE до общего объема сегментов виртуальной памяти и перезагрузите экземпляр. Обратите внимание, чтобы значения параметров SHMTOTAL и SHMVIRTSIZE не конфликтовали друг с другом.

В IDS 11 добавлена возможность про-активного мониторинга памяти экземпляра. в ранних версиях IDS новая порция памяти запрашивалась в том случае, когда все уже выделенные порции памяти были заняты. В IDS 11 параметр SHMVIRT_ALLOCSEG состоит из двух частей. Первая часть отвечает за время выделения памяти – выделять новую память, когда заполнен определенный процент уже выделенной памяти (диапазон .40 –.99) либо когда осталось незаполнено n килобайт выделенной памяти (диапазон 256-1000000). Вторая часть параметра отвечает за параметр серьезности, передаваемый SYSALARMPROGRAM при выделении новой порции памяти (диапазон значений 0 (не серьезно)- 5 (фатально)). Если значение первой части параметра равно 0, то память выделяется по алгоритму предыдущих версий Informix. Вы можете установить SHMVIRT_ALLOCSEG равным .85,3. Это значит, что новая память будет выделяться, когда уже выделенная память заполнена на 85% и будет сгенерировано предупреждение со статусом «внимание» (attention). Вы можете установить значение этого параметра 512,4, что означает, что экземпляр будет выделять новую порцию памяти, когда в выделенной памяти осталось свободно 512 Кбайт, при этом будет сгенерировано предупреждение со статусом «критическое» (emergency). Дополнительные сведения об этом и других параметрах файла $ONCONFIG приведены в IBM Informix Dynamic Server Administrator’s Reference Регулярно необходимо запускать и команду onstat –R, которая показывает статистику использования LRU-очередей. LRU-очереди объединены в пары и содержат вес буферы разделяемой памяти, определенные параметром BUFFERPOOL файла $ONCONFIG. Для каждой пары указываются отдельно буферы, классифицированные как «свободные» (free) и буферы, классифицированные как «измененные» (modified). Новые или модифицированные данные хранятся в буферной области памяти до их записи на диск чистильщиками страниц. Запись этих данных на диск управляется несколькими параметрами, включая параметр LRU_MAX_DIRTY файла $ONCONFIG и обработку контрольной точки. В зависимости от того, что именно вызвало запись на диск, эта запись может быть более или менее эффективной. Запись, вызванная срабатыванием параметра LRU_MAX_DIRTY, не является ни самой эффективной, ни мамой неэффективной. Вышеприведенную команду мониторинга необходимо запускать во время серьезной нагрузки на базу, чтобы отследить, как заполняются очереди. LRU-записи будут всегда, но если количество буферов в «грязных» очередях постоянно превышает процент измененных страниц для начала очистки (параметр LRU_MAX_DIRTY), то вам стоит увеличить количество LRU-очередей и /или буферов В IDS 11 внесены улучшения алгоритма мониторинга LRU-очередей.Я рекомендую включить параметры AUTO_AIOVPS, AUTO_CKPTS, AUTO_LRU_TUNNING и установить LRU_MIN_DIRTY равным 70, а LRU_MAX_DIRTY равным 80. С помощью команды onstat –F можно мониторить эффективность операций записи на диск. Команда возвращает количество фоновых записей на диск, LRU записей на диск и количество чаноквых записей на диск с момента сброса статистики. Если регулярно проводится фоновая запись на диск (самая неэффективная), то необходимо провести дополнительное исследование для выяснения, какие операции вызывают такую нагрузку на экземпляр. Третья команда, которую мы обсудим, это команда onstat –g glo. Она выводит данные о виртуальных процессорах экземпляра и о многопоточных счетчиках. Целостность базы данных, утилита oncheck Поскольку, как мне кажется, я все-таки больше администратор баз данных, а не Dynamic Server, то с утилитой oncheck я чувствую больше родства. Утилита onstat позволяет вам заглянуть внутрь экземпляра, утилита oncheck – внутрь базы данных или таблицы. Onstat работает с экземпляром в режиме «только чтение», а oncheck позволяет изменить или исправить структуры данных БД. Однако, с помощью oncheck можно исправить только индексные структуры.

В Листинге 8.13 приведены флаги oncheck. Они объединены в две отдельные группы oncheck {-cCheckOption | -pPrintOption} [-y | -n] [-q] [{database[: [owner.]table[,fragdbs | #index]] | TBLspace number | Chunk number} {rowed | page number}] [#pgs] [-h] Флаг –с – это опция проверки. Возможны такие значения CheckOption Флаг Описание

r Зарезервированные страницы (reserved pages) R Зарезервированные страницы, включая логические журналы и физический

журнал

e Экстенты с Каталоги БД [база данных] (database catalogs) i Индексы таблицы database[:[owner.] table [#index]] I Индексы таблицы и идентификаторы строки (rowids) индекса

database[:[owner.] table [#index]] х На время проверки индекса установить на таблицу разделяемую

блокировку (share lock) d Строки табличного пространства, включающие битмапы (tablespace data

rows including bitmaps) database[: [owner.] table[,fragdbs]] D Строки табличного пространства, включающие битмапы, remainder-

страницы и BLOB’ы database[: [owner.] table[,fragdbs]]

s Разделы метаданных SBLOB-пространства (SBLOBspace metadata partitions)

S Разделы метаданных SBLOB-пространства и LO-экстенты Флаг –р – опция печати (вывода на экран). Возможны такие значения PrintOption Флаг Описание r Зарезервированные страницы (-cr)

R Зарезервированные страницы, включая логические журналы и физический журнал (-cR)

e Отчет об экстентах (-се) с Отчет о каталоге (-сс) [database] k Ключи в индексе (keys in index) (-ci) database[:[owner.] table [#index]] K Ключи и идентификаторы строк в индексе (keys and rowids in index) (-cI)

database[:[owner.] table [#index]] l (маленькая буква L)

Только ключи листового уровня (leaf node keys only) (-ci) database[:[owner.] table [#index]]

L ключи листового уровня и идентификаторы строк (-cI) database[:[owner.] table [#index]]

x На время проверки индекса установить на таблицу разделяемую блокировку (share lock)

d

Строки данных табличного пространства (-cd) database[:[owner.]table[,fragdbs]][rowid] или TBLspacenum [logical_pagenum]

D Строки табличного пространства, включающие битмапы, remainder-страницы и BLOB’ы (-cD) database[:[owner.]table[,fragdbs]][page number] или TBLspacenum [logical_pagenum]

t Отчет о табличном пространстве (tablespace report) database[:[owner.]table[,fragdbs]]

T Отчет об использовании диска табличным пространством (tablespace disk utilization report) database[:[owner.]table[,fragdbs]]

p Dump-страница для заданных [table[,fragdbs] and rowid | Table [%fragpart] and rowid | TBLspace and page number] {[# pgs] [-h]}

P Dump-страница для заданных номера чанка и страницы [chunknum and pagenum] {[#pgs] [-h]}

B Отчет об использовании BLOB-пространства для заданной таблицы (таблиц) database[:owner.]table[,fragdbs]]

s Разделы метаданных SBLOB-пространства (SBLOBspace metadata partitions)

S Разделы метаданных SBLOB-пространства и LO-экстенты Ключ Описание

-q Тихий режим работы. Выводить только сообщения об ошибках -n Ответить «нет» (NO) на все вопросы

-y Ответить «да» (YES) на все вопросы

Ключи и флаги утилиты oncheck подробно описаны в IBM Informix Dynamic Server Administrator’s Reference. Там же описана и многоликость утилиты: под этим словом я понимаю возможность проверки, исправления или просто генерации отчета. Именно этим объясняется наличие двух основных ключей: -с (проверка и возможно исправление) и –р (только отчет). Оба эти ключа поддерживают набор пересекающихся между собой флагов. Сложно сказать, какие флаги более важны. Мы обсудим флаги мониторинга, которые могут проиллюстрировать отчетные возможности oncheck. Зарезервированные страницы экземпляра Команда oncheck –pr проверяет и выводит содержимое зарезервированных страниц корневого db-пространства экземпляра. Эту команду необходимо выполнить для каждого экземпляра и сохранить ее вывод где-нибудь (это часть плана восстановления). Вывод этой команды состоит из 12-ти основных секций. Каждая секция начинается с ключевого слова «Validating», за которым следует описание информации, содержащейся в секции. Ниже описаны эти секции

Информация о создании экземпляра(instance creation information). Здесь содержатся дата и время создания экземпляра, а также размер страницы по умолчанию. Кроме того, здесь указано, является ли экземпляр первичным (primary) на диске или делит диск с экземпляром SDS (shared disk secondary), а также указаны другие флаги репликации MACH-11 Конфигурационные данные экземпляра(instance configuration information). Здесь представлена практически полная копия файла $ONCONFIG. Очень полезная секция для восстановления поврежденного $ONCONFIG Информация о логическом журнале(logical log information). В этой секции представлены данные о контрольной точке (checkpoint) и физической конфигурации логических журналов экземпляра. Информация о db-пространствах (dbspace information). Содержатся логические данные о каждом db-пространстве экземпляра. Здесь нет данных о физической конфигурации (расположение чанков db-пространства): эти данные находятся в следующем разделе. Флаги статуса указывают, является ли db-пространство зеркалируемым, является ли оно простым или смарт BLOB-пространством. Здесь также приведены данные о дате и времени создания db-пространств, о том, кто их создал, и когда они последний раз бэкапились. Информация о чанках (primary chunk information). Физические данные о каждом первичном чанке экземпляра. здесь нет данных о «зеркальных» чанках. Флаги статуса указывают, находится ли чанк в состоянии он-лайн или он отключен, находится ли он на сыром устройстве или в файле, является ли частью BLOB-пространства Информация о зеркальных чанках (mirror chunk information). Этот раздел похож на предыдущий, но содержит данные о зеркальных чанках. Информация о бэкапе (backup information). Содержит данные о том, когда был создан бэкап средствами ontape или ON-Bar. В зарезервированных страниц содержится информация необходимая для восстановления до последнего целостного последовательного бэкапа (only the backup information required to execute a complete restore to the last fully consistent serial-mode backup is maintained in these reserved pages): здесь содержатся данные о активном логическом журнале и контрольной точке. Также здесь есть данные о последних бэкапах 1-го и 2-го уровня. Таблицы системного каталога (system catalog tables) Команда oncheck –pc проверяет целостность таблиц системного каталога и выводит общую статистику. Она проверяет таблицы БД sysmaster и прочих sys-БД. Как я уже говорил в Части 4, некоторые таблицы БД sysmaster представляют собой просто указатели на разделяемую память. В результате невозможно определить количество выделенных страниц, количество используемых страниц и некоторые другие количественные данные. В выводе команды эти таблицы присутствуют только в виде их названий. Для фрагментированных таблиц и индексов выводится информация отдельно для каждого фрагмента. Отчет о табличных пространствах (tablespace report) Вывод команд oncheck –pt и oncheck –pT очень похож друг на друга. Обе они позволяют просмотреть статистическую информацию таблиц базы. Опция –pT, кроме того, выводит статистику использования страниц данных и данные об индексах (index level information). Критическое различие между этими командами состоит в том, что команда oncheck –pT для своего выполнения должна мочь заблокировать таблицу. В результате если команда заблокировала таблицу, SQL-операции с этой таблицей невозможны. Как я уже упоминал в Части 6, в Informix добавлена технология «in-place alter»: при выполнении команды alter table меняются не все строки таблицы. Основные изменения структуры таблицы,

конечно, касаются всех строк, но некоторые изменения воздействуют только на добавляемые или изменяемые строки. Поэтому в одной таблице могут быть строки с разной схемой данных. Чтобы все строки измененной таблицы имели одинаковую схему данных, можно выполнить примерно такой запрос: update имя_таблицы set имя_столбца=имя_столбца where 1=1 В разделе Home Data Page Version Summary вывода команды oncheck –pT приводится количество строк каждой версии схемы. При обновлении с одной версии IDS на другую необходимо, чтобы в таблице все строки имели одинаковую схему. Поэтому перед началом обновления необходимо убедиться, что все строки в таблице приведены к одинаковой схеме. Список свободных чанков и пересечение табличных пространств Команда oncheck –pe выводит статистику использования страниц данных каждым чанком экземпляра. используя совместно эту команду и команду oncheck –pt можно определить степень пересечения табличных пространств (tablespace interleaving) в чанках и db-пространствах. Если в db-пространстве нет или мало пересечений табличных и индексных экстентов, поиск по таблице или индексный поиск происходят значительно быстрее. На практике к изменению размеров таблицы прибегают в том случае, когда она имеет 8 и более пересекающихся экстентов. Это не значит, что надо падать в панику, если вы обнаружите 9 пересекающихся экстентов. Я видел системы, которые успешно работали при количестве пересекающихся экстентов, выражавшемся двухзначным числом. В некоторых случаях в выводе команды вы можете увидеть, что два экстента таблицы разделены блоком свободных страниц. Это значит, что эти страницы раньше занимал экстент другой таблицы. При удалении таблицы страницы данных освобождаются и могут быть использованы для выделения экстента другой таблице. Сервер БД не объединяет автоматически смежные экстенты одной таблицы, поскольку в случае такого объединения необходимо пересчитать идентификаторы строк, хранимые в заголовках страниц данных, и индексные структуры. Все экстенты таблицы можно объединить в один большой двумя путями: выгрузить данные из таблицы, пересоздать ее с необходимым размером экстента и залить данные назад или перевести один из индексов таблицы в «кластерный» режим (cluster mode). Создание кластерного индекса вызывает физическую перестановку строк так, чтобы они были упорядочены по кластерному индексу. В результате экстенты таблицы, насколько это возможно, будут объединены. После объединения экстентов вы можете изменить индекс с кластерного на обычный. Еще одна опция объединения экстентов доступна в IDS 10 и старше: инициализировать схему фрагментирования по столбцу, но хранить все фрагменты в одном db-пространстве. Проверка целостности и согласованности данных и индексов Последними мы обсудим флаги oncheck, используемые для проверки целостности и согласованности страниц данных и страниц индексов. Команды oncheck –ci и oncheck –cI (заглавная буква i) используются для проверки связанности (linkage) всех узлов структуре индексов B-дерева (Btree index structure). Опция –cI, кроме того, проверяет, что ключ индексного элемента соответствует значению в строке, на которое ссылается этот элемент (verifies that the key values stored in each index element actually match the values of the row to which the index element refers). Эти команды не только выводят отчет, но и исправляют найденные ошибки. Естественно для выполнения исправления необходимо соблюсти некоторые условия. Запустить проверку индексов и данных может любой пользователь, а выполнять исправления может только пользователь informix. Если проверяемая таблица была создана с блокировкой уровня страниц (page-level locking ), то на таблицу должна быть установлена разделяемая блокировка (share lock). Это требование может повлиять на выполнение пользовательских операций. Будьте внимательны

при проведении исправления индексов. У меня были случаи, когда утилита рапортовала, что индекс починен, но последующий запуск диагностики показывал, что индекс по прежнему поврежден. Я обычно просто пересоздаю такой индекс. Пересоздание индекса по времени сопоставимо с его починкой. Вторая пара команд: oncheck –cd и oncheck –cD проверяет целостность страниц данных таблицы. Опция –cD также проверяет и наличие BLOB-объектов, на которые есть ссылка в строке. Ключи –pd и –pD выводят соответствующую информацию о целостности. Из-за большого объема выводимых данных я рекомендую перенаправлять вывод в файл, а не на экран (внимание: результирующий файл может быть очень большого размера) Команда oncheck –pd, oncheck -pD должна запускаться пользователем informix или root (UNIX/Linux/Mac OS X) либо членом группы Informix-Admin (Windows) Заключение В этом разделе мы рассмотрели две основные консольные утилиты мониторинга экземпляра и проверки целостности элементов БД. Хотя более-менее подробно мы рассмотрели очень немногие применяемые флаги, но остальные описаны в приведенных таблицах. На данный момент вы должны понимать разницу между onstat и oncheck и для чего применяется каждая из них. Напоминаю, что почти вся информация, предоставляемая утилитами, генерируется с помощью запросов к БД sysmaster и другим sys-БД через интерфейс SMI.

Приложение Вычисление размера таблицы На сайте поддержки книги http://www.xmission.com/~dbaresrc/foundation.html вы найдете два документа в формате Adobe Acrobat и два Java-метода, которые можно использовать для определения размера первого и последующих экстентов таблицы. «Простой» метод предназначен для таблиц, у которых одна или несколько строк помещаются на странице db-пространства. «Полный» метод применяется для тех таблиц, у которых строка данных не помещается на одной странице, и поэтому возникает необходимость определить количество полностью заполненных страниц и частично заполненных. Оптимально, конечно, в таком случае перенести такую таблицу в db-пространство с большим размером страницы, но это не всегда возможно. Давайте кратко рассмотрим шаги определения размера таблицы. Сначала используем «простой» метод, а затем «полный». В обеих случаях для расчета будет применяться размер страницы в килобайтах (2 КБ, 4 КБ, 10 КБ) и размер пространства, отводимого для хранения данных на странице (в байтах) (the actual usable data storage space on the page in bytes) Перед началом обсуждения необходимо сделать несколько замечаний. Длина строки данных в таблице зависит от наличия в этой строке BLOB-объектов, а также от того, хранятся ли эти объекты в простом BLOB-пространстве либо же оставлены «в таблице». если BLOB-объекты размещены в отдельном пространстве, то при определении размера таблицы необходимо учесть только размер дескриптора BLOBa (указатель на то, где лежит этот BLOB). Такой дескриптор имеет размер 56 байт. Поэтому считайте длину поля BINARY/TEXT равной 56 байт. Если BLOB-объекты находятся в таблице, то для определения размера этих объектов можно поступить так: 1. вычислить объем страницы данных, который можно использовать, по следующей формуле (используемый размер страницы – это размер страницы в байтах – 28 байт заголовка) используемый_размер_страницы – 4 дополнительных_байта 2. определить «средний» размер BLOBа для каждого типа BLOB-объектов таблицы. Методику выполнения этого действия смотрите в Части 5 «Создание пространств» 3. вычислить количество страниц данных, занимаемых средним BLOBом путем деления среднего размера BLOBа (определен в шаге 2) на объем страницы данных, который можно использовать (определен на шаге 1) средний_размер_BLOBа / используемый_объем_страницы_данных 4. общий объем, занимаемый BLOBами в килобайтах: (количество_BLOBов * количество_страниц_среднего_BLOBа)* размер_страницы_данных_пространства Результат, полученный в пункте 4, необходимо прибавить к результатам для других столбцов и в конце получить объем пространства, необходимый для хранения данных таблицы. Если вы используете smart BLOBы, то дескриптор BLOBа равен 72 байта. Smart BLOBы всегда хранятся в отдельном пространстве, и размер этого пространства необходимо вычислять независимо. Использование простого метода В строку 101 вставьте начальное количество строк таблицы. В строке 102 укажите количество строк, которое, по вашему мнению, будет в таблице через 6 месяцев. В строке 103 укажите размер

строки данных, полученный путем суммирования размера каждого столбца строки, и добавьте 4 байта. Если в таблице есть столбец varchar, то при расчетах используйте среднюю длину данных в этом столбце. По поводу BLOB-объектов смотрите выше. В строке 104 вычислите количество строк, которые поместятся на одну страницу данных: разделите размер страницы данных (в байтах, т.е. 4068 байт для 4 КБ страницы) на размер строки данных (строка 103). Округлите полученный результат до ближайшего целого вверх. Если получившийся результат больше 255, то примите результат 255, поскольку на одной странице данных может храниться не более 255 строк В строке 105 вычисляется объем диска, необходимый для хранения начального количества строк таблицы (в КБ). Разделите количество строк (строка 101) на количество строк на странице данных (строка 104). Округлите результат до целого. Этот результат представляет собой количество страниц данных, необходимых для хранения строк. Для определения необходимого объема диска умножьте количество страниц на размер страницы db-пространства (2, 4, 10). Вы получите дисковый объем в килобайтах. Для определения размера следующего экстента используется такой же метод. Разделите количество строк (строка 102) на количество строк страницы(строка 104), умножьте получившееся на размер страницы db-пространства и поделите результат на 7. Эта формула дает несколько больший размер последующего экстента, но позволяет вам создать некоторый запас прочности на тот случай, когда таблица растет более быстро, чем вы предполагали. Последний расчет по этому методу поможет вам оценить, стоит ли хранить данные в db-пространстве с другим размером страницы. Идея заключается в максимизации количества строк, хранимых на одной странице данных. Для строк малого размера этот расчет не всегда оправдан, поскольку, как вы помните, на одной странице данных можно хранить не более 255 строк. Если количество строк на страницу данных гораздо меньше, и, следовательно, много места на странице данных не используется, попробуйте применить приведенный алгоритм с различными размерами страницы данных db-пространства. Для оценки объема неиспользуемого пространства страницы умножьте количество строк на одной странице (строка 104) на размер строки (строка 103) и вычтите то, что получилось, из используемого размера страницы Использование полного метода Этот метод ориентирован на таблицы, в которых размер строки данных превышает размер страницы данных. Если размер строки данных больше, чем используемое пространство страницы данных, то Informix Dynamic Server создаст так называемые домашние и остаточные страницы(home and remainder pages). Сначала строка таблицы размещается на домашней странице, а оставшаяся часть строки объединяется с оставшимися частями других строк и размещается на остаточных страницах. При наличии такой таблицы вам необходимо вычислить необходимое количество домашних и остаточных строк. Первые четыре поля идентичны полям простого метода. После проведения вычислений необходимо учесть, что мы работает с домашними и остаточными страницами. Для остаточных страниц необходимо меньше служебной информации, поэтому их полезный объем больше. Это необходимо учитывать при расчете того, сколько остаточных страниц необходимо для хранения остатка строки. В строке 105 производится вычисление объема остаточной информации путем вычитания из размера строки данных (строка 103) используемого объема страницы + 8 байт. Если полученный результат больше, чем используемый объем остаточной страницы, то строка данных займет не только домашнюю и остаточную страницу, но и вторую остаточную страницу. В таком случае необходимо определить, сколько полных остаточных страниц будет в таблице (строка 106) и сколько будет остаточных страниц, заполненных частично. Если значение в строке 105 меньше, чем используемое пространство остаточной страницы, вам необходимо произвести расчеты только для частично заполненных остаточных страниц.

Остаточный размер строки больше, чем размер остаточной страницы (строка 106) Чтобы рассчитать количество полностью заполненных остаточных страниц, разделите значение строки 105 на используемый объем страницы данных и вычтите 8 байт указателя на следующую страницу. Округлите полученный результат до целого и умножьте его на количество строк в таблице (строка 101). Внесите полученный результат в строку 106 и переходите к вычислению количества частично заполненных остаточных страниц. Остаточный размер строки меньше, чем размер остаточной страницы Сначала необходимо рассчитать степень использования остаточной страницы. Разделите размер строки (строка 103) на используемый объем страницы и вычтите 8 байт. При расчете необходимо использовать операцию остатка от деления (mod) , и к результату прибавить четыре (см. пример). Затем полученное значение разделите на используемый объем страницы и получите необходимую степень использования (строка 107). Например. Вы рассчитываете степень заполнения остаточной страницы для строки размером 7500 байт при размере страницы db-пространства 2 Кбайта. Тогда: [((7500 mod 2012)=1464)+4]/2020=0.23 Используя степень использования остаточной страницы из строки 107 и подходящее уравнение из инструкции, рассчитайте значение строки 108. Общий объем пространства для хранения данных таблицы состоит из трех частей:

Количество домашних страниц (строка 101) Количество полностью заполненных остаточных страниц (если есть) (строка 106) Количество частично заполненных остаточных страниц (строка 108)

Полученное значение умножается на размер страницыdb-пространства, в результате получается значение в килобайтах. При вычислении размера следующего экстента можно применить многие из уже определенных величин. При вычислении строк 109 и 110 используйте ожидаемое, а не начальное количество строк. Следующий экстент также состоит из домашних страниц, полностью заполненных остаточных страниц (если есть) и частично заполненных остаточных страниц. Полученное значение необходимо разделить на 7. Java-методы позволяют вам вычислить размеры таблиц одновременно для нескольких таблиц. Эти методы основаны на тех же исходных величинах (размер строки, количество строк, размер db-пространства), что и описанные выше алгоритмы. Исходные значения записываются в текстовый файл, имя которого является параметром вызова Java-метода. Эти методы, входные и выходные файлы описаны на web-странице книги.