Почитал исправления ошибок а также известные ошибки для версии информикса 10.00.UC8 и нашел любопытную запись:
...
IC54482 ONLINE-DOCUMENT DOCUMENTATION FOR BTREE SCANNER AND ALICE MODE IS INCOMPLETE
...
Так что возможно таки добавят подробности о настройке и работе btscanner в документацию.
пятница, 28 марта 2008 г.
четверг, 20 марта 2008 г.
Комментарии в блоге
Включил добавление комментариев в блоге только для зарегистрированных пользователей сервиса blogger.com и для пользователей децентрализованной системы идентификации OpenID. Сделано это с целью защиты блога от спама. Если вы не являетесь пользователем сервиса blogger то для добавления комментариев можно зарегистрироваться у одного из провайдеров OpenID (совершенно бесплатно), после чего вы будете иметь право добавлять комментарии (причем не только в сервисе blogger.com но и в других сервисах, например livejournal, не регистрируясь на самом сервисе). Вот здесь очень подробно написано что такое и для чего нужен OpenID. Аккаунт OpenId можно получить например здесь myOpenID или здесь Verisign
вторник, 19 февраля 2008 г.
Вышел IDS 10.00.xC8
В release notes вроде ничего нового не написали. Значит отличается от предыдущих только исправлением ошибок?
пятница, 15 февраля 2008 г.
Краткое руководство по TLR
TLR - Table Level Restore, восстановление данных на уровне таблиц. Позволяет восстанавливать определенные таблицы на момент времени от нулевого бэкапа, не восстанавливая данные всего сервера. Это очень полезная функция, и появилась она впервые в 10 версии Информикса.
Для того чтобы иметь возможность использовать TLR, необходимо чтобы была включена архивация журналов транзакций в информиксе, а также наличие архива level-0. Таблицы, которые были созданы после архива level-0 не могут быть восстановлены с помощью TLR. Можно делать либо только физическое восстановление таблиц, или восстановление на момент времени после level-0. Также можно восстанавливать таблицы на другом сервере, что позволяет осуществлять миграцию выбранных данных между серверами информикс.
Подготовка к TLR
Вначале необходимо настроить конфигурационный файл $INFORMIXDIR/etc/ac_config.std. Положение этого файла может быть и другим, тогда его необходимо установить в переменной окружения AC_CONFIG.
Вот пример этого файла:
AC_MSGPATH /tmp/ac_msg.log # archecker журнал сообщений
AC_STORAGE /mnt/ac_storage # Каталог для временных файлов
AC_VERBOSE 1 # 1 вкл.сообщения 0 выкл.сообщения
Как видим все там очень просто и особых комментариев не требует. Каталог в AC_STORAGE должен иметь достаточно свободного дискового пространства для восстановления, иначе получим сообщение об ошибке в ходе восстановления.
Теперь необходимо настроить командный файл, в котором содержиться подключение к базе где лежит (или лежала) восстанавливаемая таблица, схема исходной таблицы, схема таблицы куда будут заливаться восстанавливаемые данные, опции восстановления (только физическое восстановление, или на момент времени).
Вот пример командного файла:
database adm;
create table source (
id serial,
fname varchar(15),
sname varchar(15),
station_id integer,
is_enabled boolean) in datadbs;
create table dest (
id serial,
fname varchar(15),
sname varchar(15),
station_id integer,
is_enabled boolean) in admdbs;
insert into dest select * from source;
restore to '2008-02-10 15:30:00';
При восстановлении на момент времени необходимо установить переменную окружения GL_DATETIME. Для таблиц необходимо указывать только список полей с типами данных и в каком dbspace они лежат. Остальные опции (констрейнты, индексы и т.д. игнорируются и их можно не включать). Как видим, исходная таблица source из базы adm восстанавливается в таблицу dest в той же базе но в другом dbspace, на момент времени '2008-02-10 15:30:00' после нулевого архива. При этом сама таблица source в ходе восстановления не затрагивается.
Запускаем TLR с помощью команды archecker -bvs -f cmdfile
Флаг -b предлагает искать данные и транзакции через интерфейс XBSA (т.е. если журнал транзакций архивируется с помощью onbar). Если используется ontape, то вместо флага -b надо использовать флаг -t.
Флаги -v и -s управляют выводом информационных сообщений. Флаг -f указывает расположение командного файла.
В ходе работы TLR вначале происходит поиск таблицы в архиве, затем таблица извлекается, и если надо, на нее накатываются транзакции. Сообщения о работе archecker пишет в лог который указан в AC_MSGPATH конфига.
Performans Tips:
Если требуется восстановить сразу несколько таблиц, их можно указать в одном командном файле и восстанавливать одновременно. Это быстрее поскольку сканирование архива и журналов происходит только один раз.
Можно делать физическое восстановление в external table, которая на самом деле является текстовым файлом с разделителями.
В командном файле можно указать другую базу для восстановленной таблицы, и например другой сервер.
В ходе восстановления можно фильтровать данные с помощью условия в операторе insert into ... select from ... where filter.
Для того чтобы иметь возможность использовать TLR, необходимо чтобы была включена архивация журналов транзакций в информиксе, а также наличие архива level-0. Таблицы, которые были созданы после архива level-0 не могут быть восстановлены с помощью TLR. Можно делать либо только физическое восстановление таблиц, или восстановление на момент времени после level-0. Также можно восстанавливать таблицы на другом сервере, что позволяет осуществлять миграцию выбранных данных между серверами информикс.
Подготовка к TLR
Вначале необходимо настроить конфигурационный файл $INFORMIXDIR/etc/ac_config.std. Положение этого файла может быть и другим, тогда его необходимо установить в переменной окружения AC_CONFIG.
Вот пример этого файла:
AC_MSGPATH /tmp/ac_msg.log # archecker журнал сообщений
AC_STORAGE /mnt/ac_storage # Каталог для временных файлов
AC_VERBOSE 1 # 1 вкл.сообщения 0 выкл.сообщения
Как видим все там очень просто и особых комментариев не требует. Каталог в AC_STORAGE должен иметь достаточно свободного дискового пространства для восстановления, иначе получим сообщение об ошибке в ходе восстановления.
Теперь необходимо настроить командный файл, в котором содержиться подключение к базе где лежит (или лежала) восстанавливаемая таблица, схема исходной таблицы, схема таблицы куда будут заливаться восстанавливаемые данные, опции восстановления (только физическое восстановление, или на момент времени).
Вот пример командного файла:
database adm;
create table source (
id serial,
fname varchar(15),
sname varchar(15),
station_id integer,
is_enabled boolean) in datadbs;
create table dest (
id serial,
fname varchar(15),
sname varchar(15),
station_id integer,
is_enabled boolean) in admdbs;
insert into dest select * from source;
restore to '2008-02-10 15:30:00';
При восстановлении на момент времени необходимо установить переменную окружения GL_DATETIME. Для таблиц необходимо указывать только список полей с типами данных и в каком dbspace они лежат. Остальные опции (констрейнты, индексы и т.д. игнорируются и их можно не включать). Как видим, исходная таблица source из базы adm восстанавливается в таблицу dest в той же базе но в другом dbspace, на момент времени '2008-02-10 15:30:00' после нулевого архива. При этом сама таблица source в ходе восстановления не затрагивается.
Запускаем TLR с помощью команды archecker -bvs -f cmdfile
Флаг -b предлагает искать данные и транзакции через интерфейс XBSA (т.е. если журнал транзакций архивируется с помощью onbar). Если используется ontape, то вместо флага -b надо использовать флаг -t.
Флаги -v и -s управляют выводом информационных сообщений. Флаг -f указывает расположение командного файла.
В ходе работы TLR вначале происходит поиск таблицы в архиве, затем таблица извлекается, и если надо, на нее накатываются транзакции. Сообщения о работе archecker пишет в лог который указан в AC_MSGPATH конфига.
Performans Tips:
Если требуется восстановить сразу несколько таблиц, их можно указать в одном командном файле и восстанавливать одновременно. Это быстрее поскольку сканирование архива и журналов происходит только один раз.
Можно делать физическое восстановление в external table, которая на самом деле является текстовым файлом с разделителями.
В командном файле можно указать другую базу для восстановленной таблицы, и например другой сервер.
В ходе восстановления можно фильтровать данные с помощью условия в операторе insert into ... select from ... where filter.
четверг, 31 января 2008 г.
Немного про btscanner
Итак, начну с того что настройки сканера по умолчанию (threshold 5000 и тип сканирования leaf scan) зачастую приводят к высокой нагрузке в системах где преобладают модификации данных. При таких настройках работа btscanner существенно нагружает процессоры и диски сервера, что совсем не в лучшую сторону сказывается на производительности пользовательских транзакций.
Информикс располагает двумя (начиная с версии 9.4) и тремя (начиная с версии 10) способами очистки индексных страниц:
1 способ это leaf scan, при котором каждая индексная страница перед очисткой загружается в буферный пул информикса. Эта особенность работы и является основным недостатком данного способа:
при больших размерах индексов происходит активное вытеснение страниц данных и индексов из буферного пула страницами очищаемого индекса, что в свою очередь приводит к высокой нагрузке на дисковую подсистему.
2 способ это range scan. Основное преимущество этого способа очистки индексов состоит в том что в буферный пул индексные страницы не загружаются. Вместо этого используется пул в виртуальном сегменте информикса, т.н. "легкое сканирование". В результате нет конкуренции за буферный пул между сканером и пользовательскими сессиями. Ограничение работы range scan: таким способом очищаются только detached-индексы, т.е. индексы находящие ся в собственном разделе (такие индексы появились впервые в версии 9.30). Attached-индексы как обычно будут очищаться методом leaf scan.
3 способ, который появился впервые в 10 версии информикса называется ALICE (Adaptive Linear Index Cleaning). Этот способ использует битовые карты для очистки индекса. Это позволяет загружать только определенные группы страниц индекса для очистки, что очень хорошо влияет на производительность btscanner.
Т.о. самым производительным является для btscanner режим работы ALICE. Тем не менее это новый тип сканирования и в нем могут быть свои баги.
В документации к Информиксу информации про работу и настройку btscanner минимум, то что я написал выше это сборка информации из разных источников в интернет.
Информикс располагает двумя (начиная с версии 9.4) и тремя (начиная с версии 10) способами очистки индексных страниц:
1 способ это leaf scan, при котором каждая индексная страница перед очисткой загружается в буферный пул информикса. Эта особенность работы и является основным недостатком данного способа:
при больших размерах индексов происходит активное вытеснение страниц данных и индексов из буферного пула страницами очищаемого индекса, что в свою очередь приводит к высокой нагрузке на дисковую подсистему.
2 способ это range scan. Основное преимущество этого способа очистки индексов состоит в том что в буферный пул индексные страницы не загружаются. Вместо этого используется пул в виртуальном сегменте информикса, т.н. "легкое сканирование". В результате нет конкуренции за буферный пул между сканером и пользовательскими сессиями. Ограничение работы range scan: таким способом очищаются только detached-индексы, т.е. индексы находящие ся в собственном разделе (такие индексы появились впервые в версии 9.30). Attached-индексы как обычно будут очищаться методом leaf scan.
3 способ, который появился впервые в 10 версии информикса называется ALICE (Adaptive Linear Index Cleaning). Этот способ использует битовые карты для очистки индекса. Это позволяет загружать только определенные группы страниц индекса для очистки, что очень хорошо влияет на производительность btscanner.
Т.о. самым производительным является для btscanner режим работы ALICE. Тем не менее это новый тип сканирования и в нем могут быть свои баги.
В документации к Информиксу информации про работу и настройку btscanner минимум, то что я написал выше это сборка информации из разных источников в интернет.
понедельник, 28 января 2008 г.
Как создать файл
Многие спрашивают: как создать пустой файл для чанка на файловой системе?
Отвечаю: есть по крайней мере три способа это сделать. Первый способ это использовать команду touch. Второй способ - это команда cat. И третий способ, самый извращенный это использование текстового редактора, например vi. И это не полный список способов создания пустого файла :)))
Отвечаю: есть по крайней мере три способа это сделать. Первый способ это использовать команду touch. Второй способ - это команда cat. И третий способ, самый извращенный это использование текстового редактора, например vi. И это не полный список способов создания пустого файла :)))
вторник, 22 января 2008 г.
Используем символические ссылки вместо прямых путей
Есть очень хорошее правило которому я всегда следую: никогда не указывать прямых путей к чанкам при создании dbspace и добавлении новых чанков. Всегда указывать пути к чанкам через символические ссылки. Почему? Представим следующую ситуацию: сервер информикс имеет dbspace с чанком и при создании этот чанк был указан по прямому пути. Однажды диск где лежат чанки ломается. На сервере полно места на других дисках, но при создании dbspace был указан прямой путь и чтобы восстановить поврежденные чанки из бэкапа, надо указывать старый путь, которого больше нет. Например если поврежден диск /dev/sdb1 (при использовании сырых устройств в Linux) то надо вместо него поставить в систему исправный чтобы начать восстановление, а если его нет то восстановление затягивается. Немного проще если чанки лежали на файловой системе - тогда можно путь этой ФС подменить другой смонтированной по этому пути файловой системой.
Зато если использовать символические ссылки, то таких проблем не возникнет: имя ссылки может оставаться прежним, а направить ее можно в любое место на файловой системе или диске. Так можно делать в Unix (AIX, Linux и др. системах).
В Windows на NTFS символических ссылок вроде бы как и нет. Т.е. простых средств для их создания, которые бы шли вместе с системой я не знаю. Зато есть утилиты сторонних производителей, которые позволяют задействовать эту функциональность NTFS. Например программа junction фирмы Sysinternals. Но опыта использования этого средства для указания путей к чанкам в Windows я не имею.
Зато если использовать символические ссылки, то таких проблем не возникнет: имя ссылки может оставаться прежним, а направить ее можно в любое место на файловой системе или диске. Так можно делать в Unix (AIX, Linux и др. системах).
В Windows на NTFS символических ссылок вроде бы как и нет. Т.е. простых средств для их создания, которые бы шли вместе с системой я не знаю. Зато есть утилиты сторонних производителей, которые позволяют задействовать эту функциональность NTFS. Например программа junction фирмы Sysinternals. Но опыта использования этого средства для указания путей к чанкам в Windows я не имею.
Подписаться на:
Сообщения (Atom)