Часто задаваемые вопросы по OpenEdge RDBMS

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

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

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

Автор:
Gus Bjorklund
Перевод:
Александр Леоненко
Валерий Башкатов

Часто задаваемые вопросы

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

I.            Предварительные вопросы

1.      Где я могу найти последнюю версию вопросов?

Последнюю версию можно найти на веб-сайте сообщества Progress в разделе OpenEdge/RDBMS (http://communities.progress.com/pcom/docs/DOC-107728)

2.      Почему я не нашел свой вопрос здесь?

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

3.      Что делать, если я считаю, что ответ на вопрос не правильный?

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

4.      Где я могу задать вопросы и получить ответы?

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

Онлайн-ресурсы

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

• «OpenEdge RDBMS Performance Tuning Made Simple», руководство по настройки базы данных, написанное в 2006 году, но всё еще актуальное, доступно на PSDN http://communities.progress.com/pcom/docs/DOC-14078
• «OpenEdge RDBMS Practical Internals», обсуждаются распределение пространства в базе данных и некоторые прочие интересные темы. Доступно на сайте PSDN http://communities.progress.com/pcom/docs/DOC-105267
• Progress E-Mail Group (PEG), отличное место чтобы задавать вопросы и быстро получать на них ответы. http://www.peg.com
• Онлайн-форум Progress Software Developer Network (PSDN) http://communities.progress.com/pcom/community/psdn, еще одно замечательное место для вопросов и ответов.
• OpenEdge Hive, http://www.oehive.org – содержит много статей, полезных примеров кода и библиотек.
• База знаний Progress Customer Support http://www.progress.com/support
• ProgressTalk на http://www.progresstalk.com, еще один форум, который посещают опытные администраторы базы данных OpenEdge.
• Центр компетенции Progress http://csbi-progress.ru – русскоязычный сайт по продуктам Progress Software. Здесь вы найдете множество полезных статей. Там же есть форум RuPUG (Russian Progress User Group) http://forum.csbi-progress.ru. Форум имеет более чем десятилетнюю историю и аккумулирует знания большого количества специалистов. Задав вопрос на форуме, будьте уверены – вы получите на него ответ. Форум русскоязычный.

Если вы знаете еще какие-либо полезные онлайн-ресурсы, пожалуйста, сообщите нам о них.

Документация по продукту

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

• OpenEdge Data Management: Database Administration
• OpenEdge Data Management: SQL Reference
• OpenEdge Data Management: SQL Development
• OpenEdge Getting Started: Database Essentials
• OpenEdge Getting Started: Core Business Services
• OpenEdge Deployment: Startup Command and Parameter Reference

Документацию по OpenEdge можно скачать с веб-сайта Progress Communities: http://communities.progress.com/pcom/docs/DOC-16074

II.            Основные вопросы

5.      Что плохого в использовании старых версий OpenEdge?

Есть два ответа.

Ответ №1. В зависимости от того, что вам нужно. Для многих людей, использование последней версии OpenEdge важно потому, что:

• Новые версии содержат множество новых и полезных функций, возможностей языка, базы данных и в прочих областях. Несколько примеров: новые типы данных, шифрование базы данных, аудитинг, области хранения данных второго типа, поддержка больших ROWID, поддержка веб-сервисов, объектное программирование, .NET UI, и драйвер JDBC 4, и всё это только в 10.2B. Версия 11.x содержит еще больше.
• Новые версии почти всегда содержат улучшения производительности, которые часто можно использовать без каких-либо изменений в вашем приложении.
• Новые версии активно поддерживаются службой поддержки Progress Software (PSC) и инженерной группой OpenEdge. Исправление ошибок и выпуск обновлений (Service Pack) выполняются на регулярной основе.
• Даже если служба поддержки PSC сможет ответить на вопросы и попытается найти обходной путь для проблемы, старые версии никогда не получат обновлений или исправления ошибок. Детальные знания о старых версиях со временем забываются, как в самой PSC, так и среди большого сообщества пользователей. (За исключением Юрия Потемкина, который никогда ничего не забывает)
• Новые релизы работают лучше на новых версиях операционных систем. В то время как старые версии OpenEdge могут совсем не работать на таких ОС (пример, Progress 9 не работает на Windows 7 или Windows 8).
• Переход на новую версию с текущей версии выполнить намного проще, чем сделать переход с очень старых версий.
• Архитектурные лимиты в новых версиях намного выше, чем в их предшественниках (например, увеличены максимальное количество rowid в области, максимальное размер индекса, размер сегмента r-кода, максимальная ширина окна и т.п.).

Ответ №2. «Если это работает, не трогай это» – мы все помним эту старую поговорку. Но, тем не менее, что будет, если то, что работает нормально сейчас, не сможет удовлетворить вашим потребностям спустя несколько лет? Многие системы содержат программное обеспечение, созданное разными компаниями. В конечном итоге эти компании прекращают поддержку старого программного обеспечения (Политика жизненного цикла Progress исторически подразумевает поддержку основных версий (например, 8, 9, 10) в течение, как минимум, пяти лет. Версии 9 и 10 поддерживались гораздо дольше, чем 5 лет.) и железа, или же, они станут взимать плату за продолжение поддержки, завышенную в десятки раз. Затраты могут подняться, даже в случае, если вы ничего не меняете и ничего у вас не выходит из строя.

6.      Какая самая последняя версия OpenEdge?

Последняя версия OpenEdge 11.5,  вышла в декабре 2014 года.

7.      Какой номер последнего обновления для версии 10-ой серии?

Последнее обновление 10.2B08. Это последнее обновление для данной версии – больше обновлений для OpenEdge 10 не будет (!)

8.      Какой последний релиз для версии 9-ой серии?

9.1E04. Выпущена в апреле 2006 г., это финальный релиз. Первый релиз 9-ой серии (9.0A) был выпущен в декабре 1998 г. Если вы используете 9.1E или более раннюю версию, вы определенно должны выполнить обновление.

9.      В чем разница между редакциями OpenEdge RDBMS Workgroup и Enterprise?

Редакция Workgroup предназначена для использования в инсталляциях, в которых количество пользователей не более 30, размер базы данных достаточно мал, и требования к производительности незначительны. Редакция Workgroup имеет следующие ограничения:

• Максимальное количество одновременных подключений к базе данных 65. Это подразумевает: 5 фоновых процессов и по 2 подключения для каждого из 30 пользователей (1 для приложения и 1 для инструментов запросов и отчетности). Ограничение в 65 подключений, это жесткое ограничение.
• Максимально рекомендуемые размер базы данных примерно 5 Гб. Это не жесткое ограничение.
• Максимальный размер экстента базы данных 2 Гб. Это жесткое ограничение. Область данных и область Primary Recovery (Before Image Log) должны разделяться экстентами по 2 ГБ (или меньше).
• Размер блока базы данных не может быть выбран при создании новой базы данных. С тех пор, как размер блока по умолчанию был увеличен, это теперь не важное ограничение.
• Нельзя использовать фоновые процессы ввода/вывода Asynchronous Page Writers, Before-Image Writer и After-Image Writer (Тем не менее, механизм After-Imaging можно использовать, и так было всегда.) .
• Чекпоинты (Checkpoints) синхронные, а не асинхронные. Это означает, что вы не можете использовать размер кластера Before-Image больше чем 128 Кб, так как синхронные чекпоинты происходят каждый раз, когда кластер заполнен. Чем больше размер кластера, тем больше будет нагрузка ввода/вывода в конце чекпоинта. Размер кластера по умолчанию 512 Кб.
• Нельзя использовать параметры конфигурации –spin, -nap и –napmax.
• Нельзя использовать параметр конфигурации альтернативного буферного пула (-B2). Любые таблицы и индексы, которым указано использовать альтернативный буферный пул, будут проигнорированы, и для них будет использоваться только первичный буферный пул.
• Использование параметра конфигурации –semsets не допускается.
• Использование NFS для хранения базы данных не допускается.
• Использование функции Quiet Point для выполнения раздельного зеркального резервного копирования (split-mirror backup) и выполнения резервного копирования созданием снимков файловой системы (snapshot backup) не допускается
• Функция шифрования базы данных Transparent Data Encryption недоступна.
• Функция кластерного менеджера Failover Cluster недоступна.
• Возможность участия в распределенных транзакциях, охватывающих множественные X/Open XA ресурсы с использованием JTA (Java Transaction API) недоступна.
• Для релизов старше 10.1B функция репликация  базы данных (OpenEdge Replication) недоступна.

III.            Хранение базы данных

A.     Файловая система

10.      Какие файловые системы поддерживает Progress?

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

В основном, Progress Software не поддерживает или не сертифицирует файловые системы или устройства хранения для использования в качестве хранилища OpenEdge RDBMS. Файловые системы, это часть операционной системы, также как драйверы устройств, их поддержку осуществляют соответствующие поставщики операционной системы. Если появляются какие-либо ошибки или недостатки, то Progress не может их исправить – за это несет ответственность поставщик операционной системы.

СУБД OpenEdge хорошо работает с большинством файловых систем при условии, что API доступа к файлам операционной системы реализована правильно, правильно настроены параметры файловой системы и установлены необходимые обновления от поставщика, если таковые были.

Только в очень редких случаях Progress Software сертифицирует файловые системы или другие продукты для хранения данных в качестве хранилища OpenEdge RDBMS. Такие сертификации делались в порядке исключения, и, как правило, в сотрудничестве с соответствующим поставщиком. По состоянию на май 2012 г. были протестированы и сертифицированы только NetApp Filer (сертифицировано начиная с 9.1C и выше) и EMC SRDF (сертифицировано начиная с 10.1C и выше). Целью этой сертификации было определить возможность работы с этими продуктами, а не что они будут соответствовать вашим требованиями. Корпорация Progress Software не рекомендует, но и не препятствует их использованию.

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

11.      Какую файловую систему следует использовать для хранения базы данных?

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

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

• Linux: ext2 или ext3
• AIX: JFS2
• HP-UX: VxFS
• Solaris: UFS или VxFS
• Windows: NTFS

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

• FAT16 and FAT32 (Windows)
• HFS (HP-UX)
• ReiserFS (Linux)

Комментарии относительно прочих файловых систем:

• ZFS. В современных выпусках Solaris доступна новая файловая система, называемая ZFS. Эта система имеет различные привлекательные качества, и мы слышали о нескольких клиентах, которые успешно используют её для хранения базы данных. В тоже время, некоторые из них считают, что у неё недостаточная производительность (но не все). Поэтому, если вы решите использовать ZFS, убедитесь в том, что у вас установлена последняя стабильная версия (Не берите на себя роль бета-тестера в собственной производственной среде). Потратьте время на изучение утилит ZFS и на настройку системы должным образом.
• Ext4. Новая файловая система для Linux, предназначенная для замены ext3. По состоянию на октябрь 2010 г. она была слишком новой и неустойчивой, чтобы использовать в производственной среде. Пока не стоит её использовать.
• Btrfs. Новая файловая система для Linux, работающая по принципу «копирование при записи» (copy-on-write). По состоянию на октябрь 2010 г. она была слишком новой и неустойчивой, чтобы использовать в производственной среде. Пока не стоит её использовать.
• RedHat GFS и GFS2, распределенная кластерная файловая система, позволяющая серверам Linux разделять общее хранилище. Когда несколько узлов кластера разделяют файловую систему GFS, кэш файловой системы должен быть синхронизирован между активными узлами. Это достигается за счет использования распределенного менеджера блокировок для достижения соглашения между узлами о том, кто из них имеет последнюю версию блоков файловой системы и файловых дескрипторов. Поскольку синхронизация требует дополнительных связей между узлами, производительность файлового ввода/вывода будет ниже по сравнению с локальными файловыми системами. У нас нет опыта работы с GFS, и мы не знаем тех, кто её использует. Пока мы не рекомендуем использовать эту файловую систему.
• Вы должны избегать использования любых новых или экспериментальных файловых систем, пока не станет известно об их надежности. Предоставьте возможность другим проверить их в первую очередь.

12.      Должен ли я включить поддержку больших файлов в файловой системе?

Да, абсолютно. Большинство файловых систем в наши дни имеют поддержку больших файлов по умолчанию, но вы должны убедиться в том, что вы используете именно их. Не забывайте, что файловые системы используются и для хранения резервных копии и журналов After-Image. Обратите внимание на то, что файловые системы FAT32 имеют максимальный размер файла 2³²-1 байт и не должны использоваться для хранения базы данных, потому что существуют другие файловые системы, которые работают лучше.

Если вы используете редакцию OpenEdge RDBMS Enterprise, вы также должны включить поддержку больших файлов для своих баз данных.

B.     Экстенты базы данных

13.      Какой размер экстентов я должен использовать?

Пока размер базы у вас не большой, наименьший размер фиксированного экстента, который вы должны использовать, должен составлять 1 Гб, за исключением, After-Image-экстентов. В общем, чем больше, тем лучше, конечно в разумных приделах. В современных файловых системах большие размеры экстентов не влияют на производительность (FAT16 и FAT32 не являются современными файловыми системами, и вы не должны их использовать для хранения базы данных. Вместо этого, используйте их, например, для хранения своих фотографий). Вы можете использовать экстенты размером от 10 до 16 Гб (Вы можете заметить, что чрезвычайно большие экстенты (например, более 10 Гб) могут отнимать много времени при перемещении или копировании.) . В настоящее время, мы не знаем никого, кто использует более крупные. Максимально возможный размер экстента в OpenEdge RDBMS в настоящее время составляет 1 терабайт (около 1000 Гб). Благодаря нескольким большим экстентами, вместо множества маленьких, используется меньше ресурсов операционной системы, таких как дескрипторы файлов (Каждый процесс, который подключается к базе данных напрямую, открывает все файлы базы данных. Учтите, что если у вас будет 1000 экстентов и 500 самообслуживаемых (self-serving) подключений к базе данных, то в операционной системе будет использоваться более 500 000 дескрипторов для открытых файлов.), количество которых ограничено. Кроме того, открытие базы данных будет более эффективным, когда открывается меньше файлов.

Редакция OpenEdge RDBMS Workgroup не поддерживает размер экстента более 2 Гб.

14.      Как я могу добавить экстент в базу данных?

Экстенты принадлежат областям хранения. Для добавления экстента в область хранения используется утилита prostrct add.

Сначала необходимо подготовить файл описания структуры базы данных (он же .st-файл), который должен содержать описание области, тип экстента и место его размещения. Следующий пример структурного файла позволяет создать и добавить один экстент фиксированного размера в область «area 51» в базе данных с именем «foo», которая уже содержит 7 экстентов.

# temp.st
#
d "area51" /db/area51/foo_51.d8 f 1000000

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

В завершении выполняем команду prostrst add, используя подготовленный структурный файл:

prostrct add foo temp.st

На этом всё. Теперь стартуем базу данных.

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

15.      Должен ли я включить поддержку больших файлов в базе данных?

Да, возможно. Под «большими файлами» мы подразумеваем, что размер файлов базы данных будет превышать 2 Гб. Для этого вам необходимо указать базе данных, что она может работать с такими файлами (Существует две явные причины, способствующие принятию решения о включении поддержки больших файлов : во-первых, когда эта функция была добавлена не все файловые системы могли работать с большими файлами или поддержка больших файлов не была в них включена; во-вторых, редакция Workgroup не позволяет использовать большие файлы.). Обратите внимание, что для включения поддержки больших файлов требуется редакция OpenEdge Enterprise RDBMS.

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

16.      Не станет ли triple indirection причиной снижения производительности при работе с большими файлами?

Маловероятно, что вы столкнетесь с triple indirection. Во-первых, это может произойти только в определенных файловых системах, таких как UFS в UNIX. Во-вторых, это было важно, когда использовались небольшие размеры блоков файловой системы, которые сейчас не являются значением по умолчанию.

В UFS, если вы используете блок файловой системы размером 2048 байт, то triple indirection будет проявляться для файлов с размером более 512 Мб, для блоков размером 4096 байт – для файлов с размером 4 Гб, для блоков размером 8192 байт – для файлов с размером более 4 ГБ. Другие файловые системы, такие как JFS, не используют triple indirection вообще.

17.      Какие типы экстентов лучше использовать, переменного или фиксированного размера?

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

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

Преимущества использования экстентов переменного размера:

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

Недостатки использования экстентов переменного размера:

• Существует незначительное влияние на производительность в момент выделения пространства на диске при расширении экстента. Размер этого влияние варьируется в зависимости от конкретной операционной системы и типа файловый системы, которые вы используете. И вероятно, что заметные различия проявятся только в инсталляциях с очень большим количеством пользователей (более 500) и с очень большими объемами транзакций.
• Экстенты переменного размера используют переменный объем дискового пространства. Есть некоторая вероятность, что не окажется достаточно свободного дискового пространства и очередное расширение экстента переменного размера окажется невозможным.
• Из-за того, что экстенты расширяются по мере необходимости, со временем, когда на одной файловой системе размещается более одного экстента, файлы могут стать фрагментированными. Соответственно, при наличии фрагментации, производительность снижается, а распределение пространства может отнимать больше времени. Однако это вряд ли может стать проблемой до тех пор, пока файловая система не близка к заполнению. Фиксированные экстента создаются сразу и, скорее всего, будут размещены последовательно.

Дополнительно прочитайте разделы о механизмах Before-Imaging и After-Imaging, где дополнительно рассказывается об их экстентах.

18.      Как зафиксировать размер переменного экстента?

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

C.      Размер блока

19.  Какой размер блока базы данных использовать?

Для лучшей производительности необходимо использовать наибольший размер блока, который доступен в OpenEdge RDBMS. На сегодня это 8192 байт. Кроме того, в файловой системе размер блока, размер страницы, размер кластера, должны соответствовать размеру блока базы данных.

В Linux-системах на базе процессора Intel размер блока файловой системы ограничен 4 Кб. Таким образом, вы должны использовать размер блока для базы данных равным 4Кб. В ответе на следующий вопрос объясняется почему.

В Windows, размер кластера в файловой системе NTFS по умолчанию 4Кб. Если вы собираетесь использовать блок базы данных с размером 8Кб, то вы должны создать новую файловую систему с размером кластера 8Кб.

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

20.  Чем плохо использование размера блока данных, большего, чем размер блока файловой системы?

Когда размер блока данных представляет собой число, кратное размеру блока файловой системы, например 8k и 4k, то большую часть времени, все работает отлично. Когда база данных записывает блок данных на диск, операционная система будет записывать данные в два блока файловой системы. Если два блока файловой системы являются смежными, требуется только передача на диск, которая вдвое больше размера блока, и обычно это и происходит. Однако если два блока являются не смежными, то операционная система сделает две отдельных дисковых операции в разные места. Есть очень небольшая вероятность, что если питание отключится сразу после записи первого блока, но перед записью второго, второй блок будет потерян. Это приведет к повреждению блока базы данных, потому что половина его будет новой, а половина – старой. Для областей данных типа II база данных может определить такую ошибку, но не может ее исправить.

21.  Как можно определить размер блока файловой системы?

Во многих UNIX и Linux системах команда df ‐g перечислит все смонтированные файловые системы и информацию о них, включая размер блока.

В AIX используйте команду lsfs ‐q /<filesystemname>

В Windows используйте команду fsutil fsinfo ntfsinfo <drive letter>:

22.  Как можно задать размер кластера NTFS в Windows?

Для создания новой файловой системы используйте следующую команду (предупреждение: все файлы на диске будут уничтожены без возможности восстановления):

format <drive>: /fs:ntfs /A:8k

D.     Области хранения

23.  Что такое области хранения данных типа II?

Области хранения данных типа II (SAT-II) используют метод распределения пространства для таблиц и индексов, отличающийся от используемого для областей данных типа I (SAT-I). Это дает ряд преимуществ в производительности и обслуживании базы данных.

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

В областях данных типа II пространство выделяется для объектов данных (таблицы, индексы и LOB) единицами, размером равным размеру кластера выделения памяти (storage allocation cluster) области хранения. Кластер равен целому числу смежных блоков базы данных. Кластеры объекта, такого, как таблица, обслуживаются связанным списком, и данные из различных объектов не смешиваются в одном кластере. Это обеспечивает различные преимущества по сравнению c областями данных типа I, включая:

• Улучшенная локальность ссылок
• Улучшенная эффективность ввода/вывода
• Уменьшенная фрагментация таблиц и индексов
• Более высокая степень параллелизма при добавлении строк в таблицы и записей в индексы
• Гораздо более высокая скорость при перестроении одиночного индекса или всех индексов в таблице
• Шифрование индивидуальных таблиц и/или индексов
• Настройка отдельных таблиц и/или индексов для использования альтернативного буферного пула
• Использование различных настроек для конфигурационных параметров create limit и toss limit для различных таблиц в той же области при необходимости
• Утилита двоичной выгрузки может выгружать всю или часть таблицы без использования индекса
• Удаление таблицы происходит практически мгновенно
• Общая производительность базы данных улучшается в большинстве случаев

Области данных типа II имеют следующие недостатки:

• Они могут занимать больше дискового пространства, чем области типа I. Каждый объект в области данных типа II занимает минимум один кластер, и в среднем каждый объект содержит один наполовину заполненный кластер. Предположим, у Вас имеется 1000 таблиц и 1000 индексов, а блок данных имеет размер 8k. При минимальном размере кластера, равном 8, требуется начальное пространство в 16000 блоков данных или 128 мегабайт. С другой стороны, дисковое пространство дешево и 128 мегабайт – это не очень много.

В тесте сравнения производительности (мы использовали ATM бенчмарк со 150 пользователями) областей данных типа I и II в версии 10.0A (первая версия, которая поддерживает области данных типа II) мы обнаружили, что области данных типа II имеют пропускную способность на 40% выше. Эксперименты с реальными приложениями в промышленной среде также показали значительно более высокую производительность при использовании областей данных типа II.

24.  Следует ли использовать области данных типа II?

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

25.  Следует ли использовать области данных типа I?

Нет. Единственным исключением является Schema Area, которая должна быть областью данных типа I. Никакие ваши данные не должны размещаться в Schema Area.

26.  Чему равен правильный размер кластера для областей данных типа II?

Большой разницы здесь нет, но в целом, 8 или 64, вероятно, является хорошим выбором. Предположим, у вас есть таблица с размером записи таким, что 8k блок данных содержит 50 записей. При размере кластера 8, новый кластер потребуется после создания 400 строк. При размере кластера 64, новый кластер потребуется для каждых 3200 записей.

Для областей данных, которые содержат большие и быстро растущие таблицы 512 будет лучшим выбором.

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

Заметим, что какой бы размер кластера вы ни использовали, каждая таблица и индекс в области данных будет занимать один кластер, даже если таблица пустая. Тогда, при размере кластера 512 и размере блока данных 8k, 1000 таблиц и 1000 индексов займут 2000 кластеров по 4 мегабайта каждый, или 8000 мегабайт. При размере кластера 8 они займут 128 мегабайт, что незначительно.

27.  Как можно конвертировать области данных типа I в тип  II?

Вы должны переместить данные из существующей области данных типа I в область данных типа II. Смотри «Как переместить таблицу в другую область?».

28.  Следует ли использовать несколько областей для различных  RPB или можно использовать один подходящий размер?

Используйте походящее в большинстве случаев значение 64, если только у вас не маленькие записи. В версии 10.1B и более поздних практически нет потерь при выборе значения maximum-rows-per-block больше «оптимального». Мы слышали, что при выборе значения maximum-rows-per-block 256 может быть чрезмерная фрагментация записей.

29.  Как рассчитать правильное значение maximum-rows-per-block (RPB) для таблицы?

Этот параметр не нужно рассчитывать вообще, хотя возможны исключения в крайних случаях. Если Вы не используете версию до 10.1B и обеспокоены пределом rowid, не беспокойтесь – это не стоит затраченных усилий.

При размере блока данных 8k правильным значением будет 64, если у Вас нет таблиц с маленькими записями. Под маленькими мы понимаем записи со средним размером менее 104 байтов, в соответствии с отчетом proutil tabanalysis. Если записи маленькие, используйте значение 128. В настоящее время нет никаких преимуществ при использовании значений, меньших 64.

В версиях до 10.1B существовал верхний предел rowid, равный приблизительно 2.1 миллиарда записей (и их фрагментов) на область данных. Использование неправильного значения RPB существенно уменьшало этот предел, что делало правильный выбор этого значения важным для больших таблиц. Выбор слишком большого значения RPB приводил к потере rowid, так как блок данных заполнялся раньше, чем все выделенные для блока rowid были использованы. Выбор слишком маленького значения приводил к потере пространства и уменьшению эффективности ввода/вывода, так как блоки данных могли быть не заполнены полностью. Каждая из этих ситуаций также уменьшает эффективное число записей, которые могут храниться. Если индексы находятся в той же области данных, каждый индексный блок еще уменьшает число доступных для использования rowid на значение параметра RPB.

Эта проблема не возникает в OpenEdge 10.1B и более поздних версиях, так как тип rowid был расширен до 64 бит. В 10.1B и далее, выбор слишком маленького значения maximum-rows-per-block по-прежнему будет приводить к потере пространства, но выбор значения больше оптимального менее опасен. Вы по-прежнему будете терять неиспользуемые rowid, но сам их верхний предел намного выше.

E.      Другие связанные с хранением темы

30.  Что такое «scatter factor»?

Scatter factor представляет собой одно из значений, включаемое в отчет анализа таблиц, выдаваемое proutil dbanalys. Это приблизительная мера плотности упаковки записей в таблице, независимо от их порядка. Это совершенно бессмысленно для маленьких таблиц. Это также не очень полезно для таблиц, которые находятся в областях данных типа II.

Чем ниже scatter factor, тем меньше операций ввода/вывода потребуется для чтения всех строк таблицы, либо путем сканирования таблицы, либо по подходящему индексу, если такой существует. Чем выше scatter factor, тем дальше одна строка находится от другой. Команда proutil tabanalys вычисляет scatter factor для таблицы, измеряя расстояние между строками одной таблицы при сканировании всех блоков в области данных. Строки одной таблицы, хранящиеся в одном блоке, имеют нулевое расстояние. Строки в различных блоках имеют расстояние, равное 1 + число блоков между ними. После расчета всех расстояний, вычисляется общее расстояние для всей таблицы, а также оценивается минимальное расстояние, если бы все строки были упакованы так плотно, как это возможно. Затем вычисляется scatter factor по формуле:

Scatter factor = log10 (Total distance / Minimal distance) + 1

Scatter factor для таблицы, упакованной до минимального расстояния, равен 1.0. Scatter factor для таблицы, растянутой в 10 раз больше минимального необходимого числа блоков данных, равен 2.0. Если у Вас проблема с производительностью, в этом участвует конкретная таблица, и она имеет scatter factor более 4, вы должны рассмотреть необходимость ее выгрузки и загрузки. Перед выгрузкой и загрузкой большой таблицы, вы должны сначала убедиться в отсутствии других проблем, например, таких, как ваше приложение делает сканирование таблицы, например, таблица не имеет правильных индексов.

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

31.  Каких действий требуют различные значения scatter factor?

Согласно Дэну Форману из BravePoint, в зависимости от диапазона scatter factor вы должны предпринять следующие  действия, указанные в таблице ниже. Это относится к большим и часто используемым таблицам.

Диапазон scatter factor	Статус	Действия
1.0	Отлично	Радуйтесь
1.1 – 2.5	Зеленый	Игнорируйте
2.6 – 3.0	Желтый	Планируйте будущие действия
3.1 – 4.0	Оранжевый	Добавьте в календарный план
4.1 и выше	Красный	Выгрузите и загрузите данные

32.  Следует ли использовать абсолютный или относительный путь в файле  .st?

Нет никакой разницы. Когда вы используете файл определения структуры как входной для команды prostrct create, пути всех экстентов автоматически расширяются до полных при необходимости. Полные пути сохраняются в таблице _AreaExtent в управляющей области базы данных. Если вы затем генерируете новый файл структуры с помощью prostrct list, в выходном файле структуры появятся полные пути.

33.  Следует ли использовать RAID? Какой RAID?

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

Чем больше дисков вы используете в дисковом массиве, тем большую скорость операций ввода/вывода вы можете получить. Единственный 2-терабайтный диск может одновременно выполнять только одну операцию чтения или записи. Десять 200-гигабайтных дисков имеют ту же самую емкость, но могут выполнять 10 операций ввода/вывода одновременно.

Вы должны использовать чередование (striping), чтобы распределить файловый ввод/вывод базы данных по максимально возможному числу дисков. Это улучшает производительность и балансирует ввод/вывод равномерно по дискам. Следует использовать зеркальное отображение (mirroring) для обеспечения избыточности, так что сбой диска, который является неизбежным, вызовет минимальные потери времени. Сочетание этих двух методов известно как RAID 10 или RAID 1 + 0.

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

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

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

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

34.  В чем разница между RECID и ROWID ?

Начиная с версии 10.1B не существует важных различий.

В предыдущих версиях RECID представлялись в виде 32-разрядных целых чисел переменной длины, так же, как целочисленный тип данных в 4GL. ROWID представлялись в виде массивов байтов переменной длины, которые могли содержать значения, большие, чем 32-разрядные целые числа. Начиная с версии 10.1B, RECID и ROWID представляются в виде 64-битных целых чисел переменной длины и могут содержать тот же диапазон значений.

VI.            Вопросы по индексам

35.      Лучше ли использовать ключи из одного поля или составные ключи?

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

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

Простой пример: Предположим, что у вас есть таблица orders со следующими полями:

• order number
• order date
• customer number
• other important stuff

Если у вас есть 3 индекса, один для order number, один для order date, и один для customer number, то, когда вы хотите выполнить запрос для всех заказов одного клиента для диапазона дат, скажем, за последний год, если заказы выбираются по индексу customer number, они не будут правильно упорядочены по дате. Таким образом, в конечном итоге, вы будете выбирать все заказы для клиента, а не только за последний год, и 4GL будет отбрасывать те, которые вам не нужны.

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

В зависимости от типа запроса, 4GL может использовать одновременно более одного индекса, что иногда полезно, но не всегда, и часто не лучше, чем использование правильного составного индекса. В данном случае, это будет означать получение двух отдельных наборов записей (или иногда просто rowid-ов), используя индекс date и customer number, оба набора будут больше, чем необходимо, сортировку, вычисление пересечения и отбрасывание ненужных записей.

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

Не забывайте о запросах SQL при определении индексов. Одной из причин низкой производительности запросов SQL является отсутствие соответствующих индексов. В общем, SQL требует большего числа индексов, чем приложения 4GL. Одна из причин этого заключается в том, что SQL часто используется для ad-hoc запросов.

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

Под небольшими индексами мы здесь понимаем индексы, занимающие около 100 или меньше блоков данных.

Рассмотрим индекс с одной записью. Этот индекс будет полностью занимать один индексный блок, который будет одновременно и корневым блоком и блоком листа. Большая часть пространства не будет использована, потому что больше нет данных.

Теперь добавим еще несколько записей индекса. В конце концов, один блок станет полон или почти полон. Затем добавим еще одну запись, и блок придется разделить на два. Эти два блока листьев, вероятно, будут содержать примерно половину записей каждый. Но нам также нужен промежуточный блок (корневой блок), который будет содержать указатели на два блока листьев. Так что теперь индекс занимает три блока и не может быть сделан меньше. Конечные блоки заполнены наполовину, а корневой блок почти пуст.

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

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

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

37.      Как плотно следует упаковывать индексы?

Обе программы, перестроения индексов и уплотнения индексов, имеют параметры, которые управляют процентом заполнения для конечных блоков индекса. Оба этих инструмента используют значение по умолчанию 80 процентов. Это значение подходит в большинстве случаев индексов, которые обновляются. Для таблиц, которые доступны только для чтения, используйте 100 процентов.

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

V.            Вопросы настройки производительности

38.      Чему равно хорошее значение для -spin?

10000 – хорошая точка отсчета для начала. Для версии 10.2 5000 может быть лучше.

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

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

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

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

39.      Каково назначение буферных пулов?

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

40.      Как указать размер буферных пулов?

Количество буферов в первичном буферном пуле определяется параметром -B. Количество буферов во вторичном буферном пуле определяется параметром -B2.

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

41.      Каково наилучшее значение параметра -B?

На этот вопрос нет простого ответа – он зависит от слишком многих переменных.

Чем больше буферный пул, тем более вероятно, что нужные вам данные окажутся в памяти, и не потребуется чтение с диска. Вы не должны бояться использовать большие значения количества хранимых в памяти буферов.  100 000 или даже больше может быть разумным. Но вы не можете просто сделать его таким большим, как вы хотите. Смотрите  вопросы об ограничениях размера области общей памяти.

Мы можем предложить два сомнительных «правила большого пальца» для выбора начального значения. Для обоих правил предполагается, что база данных значительно больше, чем объем физической памяти на компьютере сервера базы данных, и что значение -B по умолчанию слишком мало.

Правило 1: Начните с размера буферного пула около 10% от размера базы данных. Здесь предполагается, что небольшая часть базы данных используется часто, а остальная – редко или вообще не используется.

Правило 2: Начните с размера буферного пула, составляющего 50-60% от объема физической памяти на машине сервера базы данных. Здесь предполагается, что остальная память требуется для других целей, и что буферный пул должен быть настолько большим, насколько это практически возможно. Но это может оказаться больше, чем вам фактически нужно (или меньше).

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

Независимо от того, какое начальное значение вы использовали, вы должны провести некоторые эксперименты. При экспериментировании, делайте относительно большие изменения. Уменьшение или увеличение -B на 10% в общем случае дает небольшой эффект или вообще не дает заметного эффекта. Лучше увеличивать или уменьшать вдвое. По мере того, как вы увеличиваете размер буферного пула, объем дискового ввода/вывода в целом уменьшается, но все меньше и меньше.

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

42.      Как вычисляется «hit ratio» для буферного пула?

«Hit ratio» для буферного пула вычисляется и показывается программой promon как процент блоков базы данных, доступ к которым был обеспечен из буфера в памяти и не требовал чтения с диска.

promon Вычисляет «hit ratio» следующим образом:

( (Total buffer requests – Reads from disk) * 100.0) / Total buffer requests

Где,

Total buffer requests равно (Logical reads + Logical writes),

Logical reads – это число запросов блока данных для получения из него данных, например строки таблицы или записи индекса. Его значение доступно в поле VST _actbuffer._logicrds

Logical writes – это число обращений к блоку данных для изменения его содержимого. Заметим, что для изменения блока, он сначала должен быть прочитан. Таким образом, изменение вызывает как logical read, так и logical write. Его значение доступно в поле VST _actbuffer._logicwrts

Reads from disk – это число блоков данных, прочитанных с диска. Его значение доступно в поле VST _actbuffer._osrds

Logical read – это запрос блока базы данных для извлечения из него данных. Logical write – это запрос блока базы данных для изменения его содержимого. В обоих случаях, если запрашиваемый блок базы данных не находится в памяти, он будет прочитан с диска в доступный буфер. В случае logical write, после того, как содержимое буфера будет изменено, буфер будет записан на диск намного позже. Он может быть изменен несколько раз до записи на диск.

43.      Каково оптимальное значение hit ratio для буферного пула?

Оптимальное значение hit ratio для буферного пула равно 100%, что возможно только если вся база данных находится в памяти или если альтернативный буферный пул достаточно велик, чтобы содержать все назначенные для него объекты. В большинстве случаев это недостижимо из-за большого размера базы данных. Вы должны стремиться получить максимально возможное значение hit ratio. Чем больше вы задаете параметр -B, тем выше становится hit ratio, асимптотически приближаясь к некоторому пределу, после которого дальнейшее увеличение -B уже не оказывает эффекта.

Небольшие изменения hit ratio означают большие изменения в интенсивности ввода/вывода. Предположим, hit ratio равно 95%, так что, если вы обращаетесь к 10000 блокам, чтение с диска будет выполняться для 1 блока из 20, или 500 чтений диска. Если hit ratio равно 99%, то чтение с диска выполняется для 1 блока из 100, или, при доступе к 10000 блокам, 100 чтений с диска. То есть здесь увеличение hit ratio на 4% представляет снижение числа операций ввода/вывода на 80%. Увеличение hit ratio с 98% до 99% снижает интенсивность ввода/вывода на 50%.

44.      Как определить,  сколько буферов используется в альтернативном буферном пуле?

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

45.      Сколько APW мне необходимо?

Обычно вам потребуется один. Для больших систем с большим количеством дисков и высокой нагрузкой от изменений, вам могут потребоваться два. Если программа promon показывает более чем однозначные значения в столбце «Flushes» экрана «Checkpoints» и  размер кластера журнала Before-Image достаточно велик, так что ваши checkpoint длятся около 2 минут или больше, это признак того, что вам может понадобиться больше APW. Если вы запустили всего один, вы можете запускать дополнительные APW в любой момент и наблюдать за эффектом. Дополнительные APW вреда не приносят,  так что, если вы обнаружите, что они не дают никакого эффекта, вы можете оставить их работать до перезапуска базы данных.

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

Если вы думаете, что вам нужно больше, чем один или два APW, обратитесь за профессиональным советом.

VI.            Вопросы обслуживания данных

46.      Я использую массив RAID. Должен ли я по-прежнему делать backup-копии?

Безусловно. Хотя дисковый массив и обеспечивает некоторую избыточность и может помочь при некоторых сбоях, он не спасет вас от наводнения и не поможет вам, если вы запустите пакетную задачу обработки конца месяца в неправильный день или введете команду rm * в неправильном месте.

47.      Как часто следует выполнять резервное копирование базы данных?

Как минимум, вы должны делать ежедневные, еженедельные и ежемесячные «холодные» копии.  Если вы используете утилиту копирования базы данных OpenEdge (PROBKUP), вы можете делать онлайн или «горячие» копии, когда база данных продолжает использоваться. Вы должны проверять ваши копии, чтобы убедиться, что они целые и что вы можете их восстановить.

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

Если вы делаете еженедельные копии и используете After-Image, то вы можете восстановить самую свежую копию и накатить файлы After-Image за неделю до точки сбоя. В этом случае вы потеряете данные лишь за несколько минут.

48.      Какие доступны инструменты для резервного копирования?

Программа резервного копирования, поставляемая с OpenEdge RDBMS, называется probkup и является предпочтительным выбором. Она может выполнять холодное (offline) копирование базы данных, также как и горячее (online) копирование. Результат может быть направлен на одну или более магнитных лент на ленточном накопителе или в один или более дисковых файлов. Программа probkup знает, какие файлы необходимо включить для создания полной копии базы данных.

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

49.      Следует ли использовать утилиты резервного копирования из UNIX или Windows, или использовать probkup?

Утилита резервного копирования OpenEdge (probkup) всегда является предпочтительным выбором. Она знает, где находятся все файлы; она знает, запущена или остановлена база данных. Утилита probkup обеспечивает самый безопасный способ резервного копирования вашей базы данных.

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

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

• Используйте утилиту резервного копирования OpenEdge (probkup) с опцией «online».
• Выполните «split mirror backup». Чтобы это сделать, вы сначала устанавливаете для базы данных «quiet point» с помощью proutil, затем выполняете расщепление вашего дискового зеркала, завершаете «quiet point», копируете файлы базы данных с неактивной стороны вашего зеркала на целевое устройство резервного копирования, и, наконец, ресинхронизируете зеркала. Вы должны учитывать, что действие «quiet point» начинается после появления в журнале базы данных соответствующего сообщения, а не после того, как закончилось исполнение команды proutil. Также заметим, что в то время, когда зеркала расщеплены, вы не имеете никакой избыточности, и дисковый сбой может быть катастрофическим. Для того чтобы этого избежать, некоторые используют диски с тройным зеркалом.
• Если у вас имеется подсистема дисковой памяти EMC, вы можете использовать функцию EMC snapshot.

Замечание для пользователей Windows: различные коммерческие утилиты резервного копирования могут влиять на работу базы данных, если база данных используется во время работы программы резервного копирования. Программа резервного копирования может устанавливать монопольные блокировки на файлы во время их резервного копирования, и это может вызвать фатальные ошибки ввода-вывода в базе данных, когда она пытается прочитать или записать в файл, заблокированный программой резервного копирования. По крайней мере, одна утилита резервного копирования может быть настроена, чтобы закрывать программы, которые имеют открытый файл, который выбран для резервного копирования. По крайней мере, одна утилита, Ferro Backup, может быть настроена для обхода блокировок открытых файлов, так что она все равно может их копировать. Однако все такие копии файлов базы данных полностью бесполезны и будут повреждены, если база данных работает во время копирования. Наилучшим способом действий является настройка утилиты резервного копирования в Windows так, чтобы она пропускала файлы базы данных и их каталоги, и использовать probkup для создания резервных копии базы данных. Сканеры вирусов также могут ошибочно помещать в карантин или удалять файлы резервного копирования и/или базы данных.

50.      Когда следует использовать опцию  -norecover для probkup?

Только если у вас возникают проблемы с восстановлением после сбоя.

Когда Вы создаете резервную копию в offline, программа копирования выполняет восстановление после сбоя после ее запуска, и затем она не включает данные журнала Before-Image в создаваемую копию, так как они не нужны и получающаяся копия будет иметь меньший размер. Опция -norecover позволяет сделать резервную копию без выполнения первого этапа – восстановления после сбоя, при этом резервная копия будет включать полный журнал Before-Image. Если у вас возникает проблема при восстановлении после сбоя, вы можете с помощью -norecover создать копию поврежденной базы данных перед попыткой ее восстановления.

Заметим, что содержимое журнала Before-Image всегда включается в резервную копию, когда вы создаете копию в режиме online.

51.      Как создать резервную копию с использованием probkup?

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

BKDATE=`date +%Y%m%d_%H%M%S`
probkup foo -com /backups/foo/foo_${BKDATE}.bak

Команда создаст резервную копию в единственном файле. Вы также можете создавать копию в виде нескольких файлов, используя параметр -vs  чтобы указать размер выходного файла. Чтобы сделать копию без необходимости вводить все имена выходных файлов, вы можете использовать скрипт, аналогичный показанному ниже (этот скрипт тестировался на системе Solaris, не содержит проверок на ошибки и может потребовать некоторых изменений в зависимости от вашего интерпретатора shell):

#! /bin/bash
#
DB_NAME="foo"
BK_DIR="/backups/${DB_NAME}"
BK_DATE=`date +%Y%m%d_%H%M%S`
BK_FILES="${BK_DIR}/${DB_NAME}_${BK_DATE}_part_"
rm -f bklist
touch bklist
COUNTER=2
while [ $COUNTER -lt 100 ]
do
echo ${BK_FILES}`printf "%02d" ${COUNTER}` >> bklist
COUNTER=`expr $COUNTER + 1`
done
echo "Starting backup of ${DB_NAME} to ${BK_DIR}"
mkdir -p ${BK_DIR}
probkup ${DBNAME} ${BK_FILES}01 -vs 100000 -com <bklist
#
FILE_COUNT=`ls ${BK_FILES}* | wc -l`
FILE_COUNT=`expr ${FILE_COUNT}`
for I in ${BK_FILES}*
do
mv ${I} ${I}_of_${FILE_COUNT}.bak
done
rm bklist
echo "Backup of ${DB_NAME} in ${FILE_COUNT} parts completed."

Резервная копия будет сохранена в виде нескольких файлов (от 1 до 99), в зависимости от размера базы данных. Каждый файл будет содержать 100 000 блоков (или то количество, которое вы указали в параметре –vs), за исключением последнего файла, который будет меньше. До тех пор, пока копия занимает 99 или меньше файлов, это будет работать. Лишние имена файлов в списке игнорируются, так что вы можете увеличить список при необходимости. Если же список слишком короткий, процесс копирования закончится с ошибкой, когда он попытается получить следующее имя выходного файла.

52.      Как восстановить резервную копию, полученную с помощью probkup?

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

• Чтобы определить, какие области хранения содержатся в резервной копии, используйте следующую команду (предполагается, что база данных называется «foo», а файл копии называется «foo_20101010.bak»).

prorest foo foo_20101001.bak -list

Это даст вам список всех областей хранения, их размеров и других параметров. Более подробную информацию можно найти в руководстве OpenEdge Database Administration. Перед восстановлением вы должны:

• Создать соответствующий файл определения структуры «foo.st» в текстовом редакторе.
• Проверить, что ваш файл структуры не содержит синтаксических ошибок.

prostrct create foo -validate

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

prostrct create foo -blocksize 8192

• Теперь восстановите резервную копию:

prorest foo foo_20101001.bak

Когда восстановление закончится, вы закончили процесс. Или нет? Как насчет других файлов, которые вам могут понадобиться, таких, как файл keystore (используемый OpenEdge Transparent Encryption), скрипт резервного копирования, файлы параметров .pf, и так далее?

53.      Как переместить таблицу в другую область хранения?

Существует несколько способов переместить таблицу и её индексы. Для небольших таблиц вы можете использовать утилиту tablemove. Она может переместить только таблицу или таблицу вместе с индексами.

Для больших таблиц использование утилиты tablemove не рекомендуется из-за большого объема создаваемых в журнале транзакций записей, которые она генерирует при создании записи в новом месте и удалении ее в старом. Например, при перемещении 35-гигабайтной таблицы и ее индексов, наблюдался рост журнала before-Image до 300 гигабайт. Вместо утилиты tablemove вы должны использовать утилиту двоичного дампирования, и затем использовать двоичную загрузку в новое место.

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

54.      Какой самый простой способ для создания локальной копии базы данных?

Имеется несколько способов.

• Самый простой способ это использовать утилиту procopy. Если вы создаете копию большой базы данных, сначала подготовьте файл определения структуры хранения, чтобы указать, где должны быть размещены экстенты.
• Вы можете создать резервную копию с помощью probkup и затем восстановить ее в нужном месте.
• Вы также можете использовать утилиту копирования файлов операционной системы, чтобы скопировать каждый экстент и файл .db в новое место. Если вы используете этот способ, вы также должны подготовить файл определения структуры, в котором будет указано новое расположение всех экстентов, и затем использовать утилиту prostrct repair для изменения нового расположения  экстентов в скопированном файле .db. Если не выполнить prostrct repair, возникнут проблемы, так как копия файла.db будет содержать полные пути к экстентам в их старом месте. Если запустить базу данных, будут использованы оригинальные экстенты, а не их копии и база данных может быть повреждена. Вы можете использовать команду prostrct list, чтобы получить текущее определение структуры.

Не забудьте о других файлах (скрипты, файлы .pf и т.д.) которые также нужно скопировать и отредактировать.

55.  Как переименовать базу данных?

Предположим, ваша база данных называется «spam» и вы хотите переименовать ее в «eggs», для этого необходимо сделать следующее:

• Получите текущий файл определения структуры, его имя будет «spam.st», следующим образом:

prostrct list spam

• Скопируйте файл «spam.st» в «eggs.st»
• Отредактируйте файл «eggs.st» и измените все вхождения «spam» на «eggs». Сохраните ваши изменения.
• Переименуйте файл «spam.db» в «eggs.db».
• Переименуйте файл «spam.lg» в «eggs.lg».
• Если вы используете файл keystore «spam.ks», переименуйте его в «eggs.ks».
• Переименуйте все другие файлы, которые содержатся в вашем отредактированном файле определения структуры.
• Измените файл «eggs.db» с новыми путями к экстентам с помощью команды:

prostrct repair eggs

• Если вы используете файл параметров «spam.pf», отредактируйте его и замените все вхождения «spam» на «eggs». Сохраните ваши изменения и переименуйте файл в  «eggs.pf».

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

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

56.  Как переместить базу данных на другой сервер?

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

Альтернативный метод, но требующий больше времени – сделать двоичный дампы всех ваших таблиц и затем загрузить их в новую базу данных на новом сервере. Файлы двоичных дампов являются переносимыми между различными операционными системами, типами процессоров и версиями OpenEdge.

57.  Как часто следует делать дамп и загрузку моих данных?

Мы слышали, что некоторые люди выполняют дампирование и перезагрузку их данных через регулярные интервалы, скажем раз в год. Это не должно быть необходимо, если вы не используете древние версии и используете области хранения типа II. Однако если вы выполняете некоторую реорганизацию, вы можете сделать это. Здесь приведены некоторые причины, по которым дампирование и перезагрузка может оказаться полезными:

• Вы выполняете конвертирование областей хранения с типа I в тип II. Вы должны перезагрузить данные. Некоторые возможности базы данных и языка 4GL требуют, чтобы данные были в областях типа II.
• Вы хотите использовать другой размер блока данных. Размер блока данных указывается при создании базы данных и затем не может быть изменен.
• Вы хотите использовать другое значение maximum rows-per-block. Это значение определяется при создании области хранения данных и затем не может быть изменено.
• Вы хотите изменить операционную систему или тип процессора.
• Вы хотите переупорядочить записи в таблице так, чтобы физический порядок хранения соответствовал некоторому конкретному индексу.

58.  Следует ли использовать «нормальный» или двоичный дамп?

Как правило, следует использовать двоичный дамп. «Нормальные» дампы выполняются в текстовом формате, в том же, который создается оператором EXPORT языка 4GL. Данные переводятся в символьный формат, разделяются символом-разделителем, значения символьных полей заключаются в кавычки. Это требует больше времени на обработку и файлы имеют больший размер, чем в двоичном дампе, который содержит записи в формате хранения базы данных.

С другой стороны, «нормальный» дамп позволит обнаружить некоторые повреждения записей, которые двоичный дамп не обнаруживает. Это связано с тем, что нормальный дамп требует декодирования каждого поля и преобразования его в символьный формат. Двоичный дамп не проверяет индивидуальные значения полей, выгружая полные записи в двоичном формате хранения их в базе данных.

Результат нормального дампа намного легче прочитать из другого программного обеспечения, чем результат двоичного дампа (формат двоичного дампа не документирован).

59.  Какой способ дампирования и загрузки данных самый быстрый?

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

Следующая информация может оказаться полезной:

• Dan Foreman, «Binary Dump & Load Checklist», доступно на сайте Progress Communities.
• Tom Bascom, доклад на Exchange 2006 «Highly Parallel Dump and Load», доступно на сайте Progress Communities по адресу http://communities.progress.com/pcom/docs/DOC-15841 (смотрите сессию DB-8) и на сайте Тома http://www.greenfieldtech.com/downloads

60.  Какой самый быстрый способ подсчитать все записи в таблице?

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

Еще один способ подсчитать строки в таблице — выполнить инструкцию SQL SELECT COUNT(*) FROM «mytable» из утилиты SQL Explorer. Утилита sqlexp использует драйвер JDBC и OpenEdge SQL Server.

Еще один способ подсчитать строки – выполнить запрос FOR EACH с опцией TABLE-SCAN. Например, так:

n = 0.
for each mytable table-scan no-lock:
   n = n + 1.
end.

61.  Какой самый быстрый способ удалить все записи из таблицы?

Самый быстрый способ удалить все записи из таблицы – это использовать оператор SQL DROP TABLE. При этом также будет удалено описание таблицы, так что ее потребуется создать заново, если она еще необходима. Соответственно, вы должны использовать словарь данных для выгрузки определения таблицы в файл.df перед ее удалением.

VII.            Вопросы по журналам транзакций

СУБД OpenEdge использует два типа транзакционных журналов: журнал Before-Image и необязательный журнал After-Image.

F.     Журнал Before-Image Log (также BI, также журнал undo-redo)

Журнал Before-Image используется для записи последних изменений базы данных и предоставляет данные, необходимые для отката транзакций и восстановления при сбоях. Пространство в журнале Before-Image автоматически используется повторно после окончания транзакции, когда ее данные больше не нужны.

62.      Как часто следует усекать журнал Before-Image?

В большинстве сред журнал the Before-Image стабилизируется на некотором «нормальном» размере, что зависит от конкретного приложения, числа пользователей, активности базы данных и ее размера. Вам не следует усекать журнал, если у вас нет каких-либо причин сделать это. Заметим, что для того, чтобы знать нормальный размер, вы должны наблюдать за нормальным функционированием системы в течение определенного периода времени, пока размер журнала Before-Image не стабилизируется.

Иногда журнал Before-Image может вырастать значительно больше его «нормального» размера, когда вы выполняете операции, которые изменяют большое количество данных, например, перемещение таблиц и индексов, удаление больших таблиц, изменение всех записей в большой таблице или обработка конца года.

Если журнал вырастает значительно больше нормального размера, вы можете рассмотреть необходимость его усечения. Обратите внимание, что горячее резервное копирование включает журнал Before-Image, так что это следует принимать во внимание. Резервные копии в режиме Offline не включают журнал Before-Image, если не используется параметр -norecover.

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

63.      Почему мой журнал Before-Image  такой большой?

Он действительно такой большой? У Вас кончается дисковое пространство? Смотрите ответ на вопрос об усечении журнала Before-Image.

Вот неполный список некоторых действий, которые могут привести к росту журнала Before-Image больше «нормального» размера:

• Обработка конца месяца, конца квартала, конца года и т.п. нагрузка, которая отличается от типичной повседневной нагрузки;
• Любые «массовые» операции, которые затрагивают большое количество данных в одной большой транзакции: обновление миллиона записей, перемещение таблиц и индексов, удаление большого количества ненужных старых данных;
• Транзакции, которые не затрагивают большого количества данных, но остаются открытыми в течение длительного времени, например, начать транзакцию и уйти на обед, домой или в отпуск;
• Увеличение числа пользователей. Обычно, чем больше пользователей, тем больше происходит изменений в базе данных. Обычно увеличение числа пользователей происходит постепенно;
• Рост размера базы данных также часто приводит к росту размера транзакций, что приводит к росту данных в журнале BI;
• Откат большой транзакции, которая была близка к завершению.

64.      Какие параметры следует использовать для журнала Before-Image вместо значений по умолчанию?

• Размер кластера для базы данных Workgroup database: 128 килобайт
• Размер кластера для базы данных Enterprise: 2048 килобайт или больше. Оптимальное значение зависит от активности базы данных. Если значение столбца «Flushes» экрана «Checkpoints» в promon равно нулю или малое и продолжительность checkpoint duration равна минуте или более, то размер кластера достаточно велик.
• Размер блока Before-Image: 8192 или 16384.

65.      Мой журнал Before-Image достиг 2 гигабайт и база данных остановилась. Что делать?

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

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

Для выхода из этой ситуации необходимо добавить больше пространства в журнал Before-Image с помощью prostrct add. К сожалению, эта утилита не позволит Вам добавить еще один переменный экстент без предварительного удаления существующего переменного экстента, а его нельзя удалить без предварительного усечения журнала BI, что требует выполнения восстановления после сбоя.

Однако вы можете использовать prostrct add для добавления фиксированного экстента BI. Затем, после выполнения восстановления после сбоя, вы можете усечь журнал Before-Image и создать новые экстенты журнала BI, сделав последний экстент переменным.

Альтернативный метод восстановления:

• Создайте резервную копию базы данных в режиме offline с указанием опции «norecovery». При этом журнал Before-Image будет включен в копию.
• Удалите существующую структуру хранения базы данных.
• Создайте новую структуру хранения и добавьте больше пространства для журнала Before-Image, добавив один или более экстентов BI.
• Используйте утилиту prostrct create для создания новой структуры хранения.
• Восстановите резервную копию в новую структуру базы данных, которая имеет больше пространства.
• Запустите базу данных снова и выполните восстановление после сбоя.

Версии до 9.0A имеют предел данных в 2 гигабайта для журнала Before-Image, даже если в экстентах BI распределено более 2 гигабайт пространства. Если вы используете такую версию, вы определенно должны перейти на свежую версию до того, как превысите этот предел.

66.      Почему мое приложение замораживается и что такое checkpoint?

Состояние работающей базы данных определяется тремя (также может быть и четвертая часть, данные в журнале After-Image, но это не имеет отношения к данному вопросу) частями:

• Данные на диске в различных экстентах данных. Некоторые из этих данных являются устаревшими и противоречивыми.
• Данные в блоках буферов в области разделяемой памяти базы данных. Некоторые из этих данных были изменены, но не записаны на диск.
• Записи журнала транзакций в Before-Image. Эти данные необходимы для отката транзакций и восстановления после сбоев.

Все обновления базы данных выполняются на месте в памяти и эти изменения не записываются на диск, когда заканчивается сделавшая эти изменения транзакция. Вместо этого, изменения могут накапливаться в памяти в течение длительного периода времени. Checkpointing представляет собой непрерывный процесс синхронизации данных на диске с изменениями, которые были сделаны в памяти. Заметим, что 100% синхронизация достигается редко и в действительности не нужна. Данные на диске почти всегда частично устаревшие. Этот процесс работает путем записи обновленных блоков данных из разделяемой памяти на диск в непрерывной серии шагов, представляющих собой отдельные контрольные точки, одна за другой. Если этого не делать, данные на диске становятся все более устаревшими.

Каждая контрольная точка начинается, когда recovery manager базы данных открывает новый кластер в журнале Before-Image Log и заканчивается, когда кластер закрывается, после чего открывается новый кластер и начинается следующая контрольная точка. При окончании контрольной точки любые блоки данных, которые были изменены в течение предыдущей контрольной точки и еще не записаны на диск, должны быть записаны. Если таких блоков много, это может занять длительное время. Следующий кластер журнала Before-Image не может быть открыт, пока не завершится процесс записи. Существует два неприятных эффекта при возникновении такой (временной) ситуации:

• Не может быть сделано дальнейшего изменения состояния транзакций или изменений базы данных. Это приведет к тому, что любой пользователь, который хочет выполнить изменение базы данных, начать транзакцию или закончить транзакцию, должен ждать, и приложение покажется «замороженным» на какое-то время.
• Пропускная способность чтения дисков будет снижена из-за высокой интенсивности записи блоков данных. Это приведет к замедлению выполнения запросов.

Для предотвращения этого, база данных использует один или несколько процессов асинхронной записи страниц (APW) для записи блоков данных на диск в фоновом режиме (заметим, что версия  Workgroup не включает фоновых процессов ввода/вывода) до окончания контрольной точки.

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

67.      Как можно уменьшить число контрольных точек?

Длительность контрольных точек определяется двумя параметрами: размером кластера журнала Before-Image и числом изменений базы данных, которые происходят в течение контрольной точки (другими словами – нагрузкой). Число изменений есть функция от числа пользователей и операций с базой данных, выполняемых вашим приложением. Контрольная точка всегда начинается, когда открывается кластер журнала Before-Image и заканчивается, когда кластер журнала закрывается. Размер кластера журнала определяет, сколько данных журнала («bi notes») может в нем храниться.

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

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

Вы можете увеличить размер кластера с помощью утилиты proutil для усечения журнала Before-Image с указанием нового размера кластера. Например:

$ proutil foo -C truncate bi -bi 4096

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

Размер кластера по умолчанию постепенно увеличивался от версии к версии от 16 килобайт до 512 килобайт. Вы должны увеличивать размер кластера до тех пор, пока ваши контрольные точки не будут продолжаться от одной до двух минут (или немного больше). Начните с 2048.

Если вы используете базу данных Workgroup, вы не должны увеличивать размер кластера. Наоборот, вы должны его уменьшить, что уменьшит количество измененных блоков, которые должны быть записаны по концу контрольной точки.

G.     Журнал After-Image (также AI, также redo log)

Необязательный журнал After-Image используется, в комбинации с предварительной резервной копией, для восстановления после сбоя носителя или других сбоев, когда экстенты данных или журнала Before-Image повреждены или утрачены. При использовании журнала After-Image, вы должны архивировать содержимое заполненных экстентов AI перед тем, как их дисковое пространство может быть использовано повторно.

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

Журнал After-Image может также быть использован для непрерывного поддержания в  «горячем резерве» почти текущей копии базы данных на другом сервере путем копирования на него экстентов AI и наката их на резервную базу данных. Для этого вам может понадобиться дополнительная лицензия на базу данных на резервном сервере.

Имеется программа After-Image Archive Daemon, которая автоматически архивирует заполненные экстенты After-Image в подходящее место по вашему выбору.

68.      Следует ли использовать журнал After-Image (AI)?

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

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

Ответ 2: Да, конечно. Все должны это использовать.

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

rm *

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

Когда администратор понял, что произошло, он восстановил вчерашнюю резервную копию в другом каталоге. Затем он отправил сообщение всем пользователям о том, что возникла небольшая проблема, и ему нужно остановить и перезапустить базу данных. Все пользователи отключились от базы данных, и файлы базы данных исчезли, как только последний процесс закрыл файлы. Затем администратор переместил восстановленную копию в оригинальный каталог базы данных и накатил журналы After-Image за текущий день (они размещались на другом диске и не были удалены), чтобы получить самые свежие изменения. Затем он перезапустил сервер базы данных и разрешил пользователям возобновить работу. Никакие данные не были потеряны. Никто ничего не заметил.

69.      Как использование AI влияет на производительность?

Многократное тестирование в течение многих лет показало, что на правильно настроенном сервере базы данных использование журналов After-Image уменьшает общую производительность базы данных на менее чем 4 процента. Это было подтверждено в производственных системах многочисленными опытными администраторами баз данных.

70.      Сколько необходимо иметь экстентов After-Image?

Вы должны иметь не менее четырех экстентов (если вы определили менее четырех экстентов After-Image, вы почти наверняка столкнетесь с проблемами). Они распределяются следующим образом:

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

Этот вариант гарантирует, что активность базы данных не остановиться и не будет простаивать, потому что нет пустых экстентов, доступных для сохранения новых записей журнала After-Image. Однако: 4 – это абсолютный минимум, лучше использовать 8. Вам может потребоваться и больше, если ваша система создает большое количество данных и экстенты быстро заполняются, или если вы используете OpenEdge Replication. Заметим также, что этот механизм предполагает, что база данных работает в многопользовательском режиме. Если вы работаете в однопользовательском режиме, то, если больше нет пустых экстентов и текущий экстент становится заполненным, база данных будет остановлена. В однопользовательском режиме вы не можете архивировать заполненные экстенты After-Image и пометить их как пустые, когда база данных используется.

Не создавайте большое количество маленьких экстентов AI. Несколько больших файлов – это намного лучше, чем множество маленьких. Например, 200 экстентов по 1 мегабайту каждый является бесполезным расточительством системных ресурсов. Если у вас больше 20 экстентов, вы должны спросить себя – почему? Для этого должна быть действительно хорошая причина.

Чтобы определить, сколько данных будет записано в журнал After-Image, используйте утилиту promon чтобы увидеть, как много контрольных точек создается в обычный день. Затем умножьте количество контрольных точек на размер кластера журнала Before-Image в килобайтах. Такое же количество данных After-Image будет записано в день.

Так как экстенты After-Image должны быть заархивированы и очищены, вы должны иметь для этого автоматический механизм. Простейший способ – использовать программу After-Image Archiver Daemon, которая может быть настроена на архивирование экстентов, когда они заполняются или через заданные промежутки времени.

Если вы используете собственные скрипты для управления экстентами After-Image и запускаете их как задачи cron, убедитесь, что они ничего не будут делать, пока вы выполняете задачи по обслуживанию базы данных или восстановлению, или когда база данных не работает. Один из способов – проверять в скриптах существование файла  (например, с именем «doaiarchive») и ничего не делать, если файл не существует. Тогда вы можете удалить файл, чтобы предотвратить выполнение скриптов, и создать его вновь (например, «touch doaiarchive»), когда вы закончили обслуживание.

71.  Как использовать After-Image Archiver Daemon?

After-Image Archiver Daemon – это фоновая программа, которая архивирует экстенты After-Image в одно или более мест назначения. После архивирования экстента, программа очищает его, так что данные («after-image notes») снова могут записываться в него. Программа архивирует экстенты либо когда они заполняются, либо в указанные периоды времени, даже если они не заполнены. Для подробного руководства смотрите главу 7 руководства Database Administration.

Чтобы использовать After-Image Archiver, предполагая, что вы уже используете журналы After-image, воспользуйтесь следующими командами.

rfutil foo -C aiarchiver enable

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

proserve foo -aiarcdir bar -aiarcinterval 3600

Программа After-Image Archiver Daemon будет запущена одновременно с сервером базы данных «foo» и экстенты After-Image будут архивироваться в каталоге «bar» каждый час. Лучше всего добавить эти параметры в файл параметров (файл «.pf»), который вы используете для запуска сервера базы данных. Тогда вы не забудете о них.

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

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

rfutil foo -C aiarchiver setdir bar

где, вы должны заменить «foo» на имя вашей базы данных и «bar» на путь целевого каталога (или на разделенный запятыми список путей). Не забудьте изменить файл параметров запуска вашей базы данных.

After-Image Archiver Daemon записывает свои действия в файле журнала с именем foo.archival.log в том же каталоге, где находится foo.db.

72.  Следует ли использовать экстенты After-Image фиксированного или переменного размера?

Вероятно, вы должны использовать экстенты After-Image переменного размера.

Преимущества использования экстентов After-Image переменного размера:

• Они могут расти по мере необходимости, и могут переключаться через регулярные промежутки времени, а не по их заполнению (например, каждые полчаса). Хотя имеются некоторые накладные расходы, вызванные периодическим расширением экстента переменного размера, в современных файловых системах эти накладные расходы обычно достаточно малы.
• Значительно снижается вероятность того, что вся активность базы данных будет приостановлена из-за того, что все экстенты After-Image заполнены.
• Когда экстент архивируется, в конце файла нет неиспользуемых блоков, что уменьшает количество данных, копируемых при создании архива.
• Когда экстент очищается, он усекается в размере и содержит только блок заголовка. Затем он снова расширяется по необходимости при записи новых данных.

Недостатки использования экстентов After-Image переменного размера:

• Существует небольшая потеря производительности, вызываемая необходимостью выделять дисковое пространство по мере роста экстента переменного размера. Величина этой потери варьируется в зависимости от конкретной операционной системы и типа используемой файловой системы. Вероятно, это создает заметный эффект только для систем с очень большим числом пользователей (более 500) и очень высокой транзакционной нагрузкой.
• Экстенты переменного размера используют переменное количество дискового пространства. Существует некоторая вероятность, что дискового пространства не хватит, и расширение экстента переменного размера может привести к ошибке. Если следующий экстент также расположен на той же (заполненной) файловой системе, он также не может быть расширен.
• Постоянное расширение и усечение экстентов After-Image может привести к некоторой фрагментации файловой системы, что в свою очередь приведет к постепенной деградации производительности файловой системы, если она заполнена приблизительно на 75-80%.

Заметим, что если вы используете After-Image Archiver Daemon для архивирования экстентов фиксированного размера и выполняете переключение по времени, в фиксированных экстентах могут быть распределенные, но не использованные блоки. Программа архивирования не копирует блоки экстентов AI, которые не содержат данных.

73.  Как создать зеркало моей базы данных с использованием журналов After-Image?

Основной процесс прост и состоит из следующих действий:

• Создайте как минимум 4 экстента After-Image для базы данных.
• Включите журналы After-Image.
• Создайте резервную копию базы данных.
• Восстановите резервную копию на другом сервере.
• По мере заполнения экстентов After-Image, копируйте их на диск и очищайте. Программа архивирования будет делать это автоматически, либо по мере заполнения экстентов, либо через определенные промежутки времени.
• Копируйте архивированные экстенты на другой сервер, используя сетевое подключение по ssh, scp или с помощью другой подходящей программы. Чтобы убедится, что файлы были скопированы успешно, можно создать маленький файл-компаньон, который содержит хэш md5 отправляемого файла. Когда пересылка файла закончится, отправьте файл хэша. Его появление на принимающей стороне указывает, что основной файл был полностью получен, и может быть использован для проверки того, что полученная копия совпадает с оригиналом.
• На другом сервере используйте утилиту наката данных для загрузки данных из экстентов в копию базы данных.

VII.            Crash Recovery

74.      Если работа моей базы завершилась аварийно, что я должен сделать для ее восстановления?

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

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

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

75.      Что произойдет, если использовать параметр -F при усечении журнала Before-image?

Краткий ответ заключается в том, что вы никогда не должны использовать параметр -F, разве что в качестве последнего средства. Если вы его используете, процедура восстановления после сбоя будет пропущена и содержимое журнала Before-Image будет потеряно. Существует очень высокая вероятность того, что в результате база данных будет повреждена.

Длинный ответ:

Состояние работающей базы данных

Полное актуальное состояние работающей базы данных состоит из трех частей:

• Данные на диске в экстентах в различных областях данных. Некоторые из этих данных устарели, так как в памяти существуют их более свежие версии.
• История недавних изменений в базе данных, записанная в журнале Before-Image.
• Измененные данные, которые еще не были записаны на диск представлены в области разделяемой памяти базы данных.

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

Нормальная остановка

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

Восстановление после сбоя

Когда база данных остановлена аварийно (например, в случае сбоя питания), все данные, находившиеся в памяти, теряются, включая любые изменения, которые еще не были записаны на диск. Все изменения базы данных выполняются «на месте» в памяти и не записываются на диск, когда заканчивается вызвавшая их транзакция. Изменения могут оставаться в памяти в течение длительного времени, возможно, несколько часов, перед тем, как они будут записаны на диск. Соответственно, данные на диске не содержат недавних изменений. Когда база данных запускается снова, database recovery manager запускает процесс восстановления после сбоя. Две основные части этого процесса это фаза redo и фаза undo. Обе они используют содержимое журнала Before-Image.

Во время фазы redo, recovery manager выполняет «сканирование вперед» записей в журнале Before-Image и повторяет любые операции, результаты которых были потеряны, потому что один или несколько измененных блоков данных не были записаны на диск.

Во время фазы undo, recovery manager откатывает любые незаконченные транзакции, читая записи в журнале Before-image в обратном порядке до записи начала транзакции. Во время этого обратного сканирования, отменяются действия всех операций, выполненных в незавершенной транзакции; изменения откатываются, удаленные записи восстанавливаются, а созданные записи удаляются.

Пропуск восстановления после сбоя

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

• Не полностью измененные записи.
• Частично удаленные записи.
• Цепочки фрагментов записи, ссылающиеся на несуществующие фрагменты.
• Записи без индексов.
• Индексы, ссылающиеся на несуществующие записи.
• Противоречивые цепочки свободных и RM-блоков  (используются для выделения пространства для новых записей).
• Логическая противоречивость из-за частично выполненных транзакций.

Пример

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

Чтобы получить запись, которая будет обновляться, нам нужно прочитать некоторую информацию с диска. Во-первых, мы читаем корневой блок индекса в один из 4 буферов. Предположим, индекс имеет два уровня, мы также будем должны прочитать конечный блок дерева индекса для того, чтобы получить recid записи. Recid говорит нам, где на диске, мы можем найти запись.

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

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

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

После того, как изменение закончилось, мы имеем следующую ситуацию:

• Мы сгенерировали четыре записи «change notes» в журнале Before-image: запись начала транзакции, две записи изменения блока, и запись конца транзакции.
• Ничего не было записано на диск. На диске мы имеем точно то же, что было вначале.
• В буферном пуле имеется два «грязных» блока, которые не были записаны на диск, но должны быть записаны в будущем.

Теперь мы читаем вторую запись, снова считывая два индексных блока. Так как предыдущие индексные блоки являются самыми «старыми», они теряются, заменяются новыми блоками и перемещаются в начало LRU-цепочки. Затем мы читаем блок другой записи, заменяя один из ранее измененных блоков, который предварительно записывается на диск. Мы не изменяем эту вторую запись. В этот момент мы имеем:

• В журнале Before-image, как и раньше, 4 «bi notes», описывающие изменение первой записи.
• На диске мы имеем один из двух измененных блоков (он был записан), а остальная база данных остается в том же виде, в котором была до начала нашего примера.
• В памяти мы имеем два индексных блока, один измененный блок записи и один не измененный блок записи.

Измененный блок записи содержит один из двух фрагментов записи, которую мы изменили ранее.

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

В этот момент происходит сбой!

Скажем, система остановилась, потому что кто-то отключил сервер, чтобы включить радиоприемник. Такое действительно случается! Но могут быть и другие причины. Может это был пылесос, а не радиоприемник. Позднее, когда мы включим сервер снова и загрузим его, мы имеем:

• В журнале Before-image log, 4 «bi notes», описывающие изменение.
• На диске, один из двух измененных блоков записи, который был записан, остальная база данных в том состоянии, в котором она была до начала нашего примера.

Все, что было в памяти, исчезло, включая один из двух измененных блоков записи. Единственным свидетельством того, что блок был изменен, является запись в журнале Before-image. Если мы сейчас запустим базу данных обычным способом, она пройдет процедуру восстановления после сбоя. Recovery manager прочитает журнал Before-image, обнаружит, что один из измененных блоков был потерян, и выполнит это изменение снова во время фазы redo. Так что теперь мы снова имеем оба измененных блока записи в базе данных. Так как транзакция была завершена, фаза undo процесса восстановления не откатит ее назад.

Теперь все в порядке.

Пропуск восстановления после сбоя

Если, вместо запуска базы данных обычным способом и выполнения процесса восстановления после сбоя, мы используем truncate bi -F, то процесс восстановления после сбоя будет пропущен и записи в журнале Before-image будут отброшены без обработки. В нашем случае, будет потеряна запись в Before-image, содержащая единственное свидетельство о том, что измененный блок не был записан на диск.

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

Перестройка индексов не восстановит поврежденную запись – у нас нигде нет никакой информации, которая может быть использована для восстановления. У Вас проблема! Выполнение truncate bi -F установит флаг «повреждено» в master-блоке базы данных, чтобы отметить факт наличия проблемы. Затем вам будет выдаваться напоминание при каждом запуске базы данных.

Обратите внимание: В старых версиях вы могли использовать трюк, иногда называемый «фиктивная перестройка индексов», когда вы запускаете программу перестройки индексов и указываете, что вы хотите перестроить некоторые индексы, но в действительности не указываете никаких индексов. Флаг повреждения базы, установленный при пропуске восстановления после сбоя, будет сброшен утилитой перестройки индексов. Вы перестанете получать предупреждение при запуске базы данных. Но ничего не было исправлено. У Вас по-прежнему есть проблема!

Повреждение не очевидно

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

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

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

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

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

76.      Если это настолько опасно, зачем вообще нужен параметр –F?

Параметр -F утилиты proutil truncate bi предназначен для использования только в аварийной ситуации как последняя мера. Он позволяет вам попытаться извлечь и спасти как можно больше  данных из поврежденной базы. Вы должны использовать его только в том случае, когда альтернативой является потеря всей базы данных.

Параметр –F должен быть вашим последним выбором, когда все остальное не сработало. Восстановление из резервной копии – гораздо более желательный и безопасный вариант.

IX.            Мониторинг базы данных

77.      Что такое VST?

Виртуальные системные таблицы (Virtual system tables – VST’s) – это фиктивные таблицы, которые отображают различные структуры данных в разделяемой памяти и позволяют представить эти данные в виде обычных таблиц так, что вы можете видеть их содержимое. Каждая из этих фиктивных таблиц имеет один фиктивный индекс. Вы можете строить запросы к этим таблицам так же, как к реальным таблицам, используя 4GL или SQL, но вы не можете их изменять.

Эти структуры данных содержать большое количество полезной информации о том, что происходит в базе данных. Они описаны в руководстве «OpenEdge Data Management: Database Administration», в главе Reference.

78.      Что делает команда proutil updatevst?

Иногда, при выпуске нового сервис пака, вносятся изменения или улучшения в виртуальные системные таблицы, например, часто добавляются новые таблицы. Определения всех виртуальных системных таблиц хранятся в базе данных в таблицах схемы. Команда updatevst программы proutil обеспечивает актуализацию этих определений и их соответствие исполняемым программам OpenEdge и структурам в разделяемой памяти.

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

79.      Почему я должен изменить параметр VST tablerange в моей базе данных?

Потому что значение диапазона таблиц по умолчанию (от 1 до 50) установлено малым, чтобы ограничить объем разделяемой памяти, используемой для статистики по таблицам и индексам. Конфигурационный параметр -tablerange используется для указания количества таблиц, для которых сохраняется статистика использования. Значение по умолчанию, вероятно, не включает все ваши таблицы. Аналогичные рассуждения применимы и к статистике использования индексов.

Заметим, что излишне большое значение конфигурационного параметра -n в комбинации со статистикой использования таблиц и индексов по пользователям может использовать большой объем разделяемой памяти.

80.      Как я могу узнать, какие индексы устарели?

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

81.      Как можно увидеть скрытые файлы на сервере базы данных?

В Linux и UNIX, используйте программу fuser, чтобы увидеть, какие файлы открыты, и программу lsof, чтобы увидеть открытые файлы процесса.

В Windows, используйте инструменты  Microsoft sysinternals. В этом наборе имеется инструмент, который называется «handle», он покажет, какие файлы открыты, и какой процесс их использует. Он также может показать список файлов, открытый конкретным процессом. Если у вас еще нет этих инструментов, воспользуйтесь Google или другой системой поиска, чтобы найти и установить их.

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

Следующая короткая программа на ABL (автор – Дмитрий Левин) рассчитывает суммарное пространство под «ватерлинией» (high-water mark) для всех областей данных:

define variable dbhw as decimal no-undo.
for each _AreaStatus where
( not _AreaStatus-Areaname matches "*After Image Area*" )
no-lock:
if _AreaStatus-Areanum <> 3 then
dbhw = dbhw + _AreaStatus-Hiwater.
end.
find first _DbStatus no-lock.
display
"DB Size"
(dbhw * _DbStatus._dbstatus-dbblksize) / 1073741824
" GB".

«High-water mark» – это наибольший использованный блок данных. Для каждой области данных он свой. Любые блоки выше него являются пустыми и не содержат данных. Программа резервного копирования OpenEdge включает в копию все блоки ниже этого блока для каждой области данных.

83.      Какие инструменты для мониторинга баз данных доступны?

Следующие инструменты доступны от Progress Software:

• promon
• Virtual System Tables и немного программирования на 4GL (детальные примеры извлечения данных из виртуальных системных таблиц можно найти в исходных текстах инструмента protop от Тома Бэскома).
• OpenEdge Explorer
• OpenEdge Management

Следующие инструменты доступны от различных партнеров:

• protop от Тома Бэскома (Tom Bascom, dbappraise.com/protop.html)
• vst dashboard от White Star (wss.com/products)
• ProMonitor от BravePoint (www.bravepoint.com)

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

X.            Виртуализация

84.      Могу я запустить мой сервер базы данных OpenEdge на виртуальной машине (VM)?

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

Хотя многие клиенты используют VMware, другие виртуальные машины тоже будут работать. Один из примеров – Amazon EC2.

85.      Что такое Amazon EC2?

Amazon EC2 – это среда виртуальных машин, которая доступна через Интернет за (небольшую) плату. Доступны виртуальные машины разного размера. Для OpenEdge на EC2 вы можете использовать виртуальные машины либо под Windows, либо под CentOS (почти идентична RedHat Enterprise Linux, от которой она и происходит). О EC2 и связанных с ней сервисах Amazon, таких, как S3, EBS и SQS, смотрите здесь: http://aws.amazon.com.

86.      Какова деградация производительности при использовании VM?

Накладные расходы, вызванные использованием виртуальной машины, изменяются от поставщика к поставщику в зависимости от типа используемой аппаратуры. Новые версии виртуализации работают лучше, чем старые, так как поставщики вносят улучшения в каждую версию. Так, накладные расходы на использование VMware в ранних версиях составляли от 30 до 50%. Современные процессоры включают функции, предназначенные для улучшения производительности виртуальных машин.

Тем не менее, вы должны ожидать снижение производительности где-то в районе от 5 до 10 процентов на правильно настроенной виртуальной машине, по сравнению с реальным компьютером. Вот некоторые причины, по которым производительность может быть ниже, чем указанная:

• Вы запускаете несколько виртуальных машин на одном сервере
• Виртуальная машина имеет меньше процессоров, чем реальный сервер
• Среда виртуальной машины имеет меньше памяти, чем реальный сервер
• Среда виртуальной машины имеет меньше дисков, чем реальный сервер
• Конфигурация гостевой операционной системы виртуальной машины отличается от конфигурации ОС реального сервера
• В виртуальной машине не включен интерфейс VMI
• Выравнивание разделов диска не является правильным в VM
• Сетевая конфигурация VM некорректна
• Другое программное обеспечение работает вне VM, что влияет на ее производительность

Конфигурирование виртуальной системы может быть сложным и, чтобы получить хорошую производительность, вам необходимо многое изучить. VMware опубликовала множество замечательных технических документов об использовании, конфигурировании и наилучших способах использования виртуальной среды VMware. Вот некоторые из них:

• Performance Best Practices for VMware vSphere 4.0 (http://www.vmware.com/pdf/Perf_Best_Practices_vSphere4.0.pdf)
• Installing and Configuring Linux Guest Operating Systems (http://www.vmware.com/resources/techresources/1076)
• Performance Best Practices and Benchmarking Guidelines (http://www.vmware.com/resources/techresources/1061)
• Scalable Storage Performance (http://www.vmware.com/resources/techresources/1059)
• Comparison of Storage Protocol Performance (http://www.vmware.com/resources/techresources/1026)
• General VMware Documentation Page (http://www.vmware.com/support/pubs/)

XI.            Безопасность

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

87.      Какие права должен иметь процесс сервера базы данных?

Некоторые из программ в каталоге $DLC/bin должны принадлежать пользователю root и иметь включенный бит setuid. Программы выполняются путем организации процесса с помощью системного вызова exec(), это то, что делает shell, когда вы запускаете _progres. Если выполняемый программный файл имеет включенный бит setuid, то эффективный идентификатор пользовательского процесса устанавливается в идентификатор пользователя владельца файла. В случае _progres, это, обычно, пользователь root (user id 0).

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

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

Следующие исполняемые файлы должны обычно иметь setuid root (что означает, что владельцем файла является root и бит setuid включен):

• _progres
• _mprosrv
• _mprshut
• _sqlsrv2

Нормальным пользователям обычно не нужно использовать _mprosrv, _mprshut, или _sqlsrv2. Если все пользователи принадлежат одной группе, то бит доступа x для _progres должен быть включен для владельца и группы, но не для остального мира.

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

Утилиты базы данных, такие, как proutil, rfutil, и т.д. должны иметь доступ на выполнение только для владельцев базы данных, и ни группа, ни мир не должны иметь прав rwx. Для управления журналами After-Image утилита _rfutil должна быть setuid root, а утилита _proutil должна быть setuid root для добавления экстентов в онлайн.

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

88.      Почему некоторые программы OpenEdge должны быть setuid root?

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

• Эти программы могут получить доступ к базам данных от имени обычных пользователей, которые не имеют разрешения на чтение или запись файлов базы данных. Это предполагает, что файлы базы данных вообще недоступны обычным пользователям, так как их биты доступа позволяют открытие на чтение и запись только для владельца базы данных и для группы администраторов. Обычные пользователи не могут создавать копии базы данных и не могут использовать текстовый редактор или другие программы для изменения файлов или их чтения.
• Эти программы подключаются к сегментам области разделяемой памяти базы данных, что недоступно обычному пользователю.
• Эти программы устанавливают их значение ulimit выше типичного значения для обычного пользователя. Это связано с тем, что файлы баз данных часто очень большие, и с большим значением ulimit они могут быть расширены при необходимости.
• Эти программы иногда координируют их действия, посылая сигналы друг другу. Например, когда база данных останавливается,  брокер базы данных посылает сигналы всем процессам, которые подключены к базе данных, чтобы информировать их о необходимости отключиться.

Заметим, что производственные системы обычно не должны иметь установленных development-лицензий OpenEdge. Вы должны использовать runtime и client-networking. Разработчики OpenEdge не должны обычно иметь доступ к производственной системе.

89.      Какие права доступа следует использовать для файлов базы данных?

На Linux и UNIX системах, права доступа к файлам и каталогам для процесса определяются эффективным идентификатором пользователя процесса, эффективным идентификатором основной группы (в некоторых системах пользователь может принадлежать более чем одной группе, перечисленной в файле /etc/group), идентификатором владельца файла, идентификатором группы владельца и 12 битами контроля доступа файла.

Доступ к файлу

Файл имеет 3 набора по 3 бита доступа (смотрите руководство по команде chmod), «r», «w», и «x» (r – чтение, w – запись, и x – выполнение) для владельца файла, членов группы владельца файла и для всех остальных пользователей (для «мира»). Бит «x» не имеет значения для файлов базы данных, он нужен для программ, скриптов shell и каталогов.

Имеется также три других бита доступа специального назначения: бит setuserid, бит setgroupid, и «sticky» бит.

Если биты доступа rw включены для владельца файла и группы, то когда процесс (например, выполняющий программу _progres) пытается открыть файл для чтения и записи, открытие разрешено, если выполняется одно из следующих условий:

• Эффективный идентификатор пользователя процесса – root (uid 0),
• Эффективный идентификатор пользователя процесса равен uid владельца файла,
• Идентификатор группы в списке эффективных групп процесса совпадает с gid группы файла.

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

Доступ к каталогу

Каталоги также имеют биты доступа rwx для владельца, группы и мира, но их значения не вполне совпадают со значениями для файлов. Когда установлен бит «r», это значит, что разрешено чтение каталога (например, с помощью команды ls). Когда установлен бит «w», это значит, что разрешена запись в каталог. Это включает создание, удаление, и перемещение файлов. Когда установлен бит «x», это значит что вы можете войти (cd) в каталог.

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

Если для каталога установлен «sticky» бит («sticky» не влияет на исполняемые файлы – это было давно и неправда), то процессы, которые имеют право на запись могут создавать и модифицировать файлы, но не могут удалять файлы, если эффективный идентификатор пользователя удаляющего файлы процесса не равен 0, не совпадает с владельцем файла или владельцем каталога.

Доступ к файлам базы данных

В большинстве случаев, когда безопасность базы данных имеет значение, нельзя, чтобы обычные пользователи имели доступ к любым файлам базы данных или каталогам, в которых они находятся. Весь доступ к базе данных обеспечивается приложением 4GL, исполняемым программной _progres, или посредством OpenEdge SQL Server через JDBC или ODBC.

Файлы базы данных (не забывайте о резервных копиях, архивах after-image, дампах данных, и других производных файлах) должны принадлежать кому-то, кто назначен администратором базы данных, или члену группы администраторов баз данных. Они не должны принадлежать пользователю root.

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

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

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

Биты «x», «sticky» бит, бит setuid и бит setgid должны всегда быть выключены для файлов базы данных.

Когда вы запускаете сервер, биты доступа к сегментам области разделяемой памяти устанавливаются равными битам доступа файла «.db» базы данных.

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

Добавление экстентов в режиме онлайн и права доступа

Когда экстенты добавляются в режиме онлайн, файлы новых экстентов базы данных создаются утилитой prostrct addonline. Биты прав доступа, идентификатор владельца и идентификатор группы для этих новых файлов определяются идентификатором пользователя и идентификатором группы процесса, который их создает, а также значением бита sticky каталога экстента базы данных.

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

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

XII.            Подключение баз данных

Смотри раздел о разделяемой памяти для дополнительных связанных вопросов.

90.      Как подключиться к одной и той же базе данных дважды?

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

Когда вы используете self-serving подключения, некоторые операционные системы (например, HP-UX) не позволяют процессу подключиться к одному и тому же сегменту разделяемой памяти более одного раза. Что не позволит вам подключиться к базе данных более одного раза, даже если вы используете разные логические имена, кроме случая, когда вы используете одно (или ни одного) self-serving подключение, а другие (или все) подключения являются сетевыми.

91.      Почему происходит ошибка оператора CONNECT, а подключение в командной строке работает?

Когда вы запускаете сервер базы данных (процесс, который запускается командой preserve, называется «брокер»; он запускает процессы серверов по мере необходимости) и он создает сегменты разделяемой памяти, он устанавливает биты доступа к сегментам разделяемой памяти аналогично битам доступа к файлу базы данных «.db». Если вы измените биты доступа к файлу «.db» после запуска сервера, это не окажет эффекта на уже установленные права доступа к сегментам разделяемой памяти, так как сервер уже получил информацию о правах доступа к файлу «.db» во время инициализации и не будет делать этого снова.

Когда вы запускаете исполняемый файл _progres, и он является  setuid root (принадлежит пользователю root и бит setuid включен), то он начинает выполняться с расширенными правами, а не с правами вашего пользователя. После завершения инициализации, включая открытие файлов базы данных и подключение сегментов разделяемой памяти, расширенные привилегии понижаются до привилегий пользователя, который запустил процесс (например, до ваших). После этого выполняется 4GL код. Это позволяет приложению иметь доступ к базе данных, даже если ваш пользователь не имеет прав на чтение соответствующих файлов. Так что код 4GL может иметь доступ к данным в базе (или к части их), но вы не можете использовать vi или другие программы для просмотра или модификации базы данных, или делать ее копии.

Оператор 4GL  CONNECT всегда выполняется с нормальными привилегиями, и никогда с расширенными, предоставляемыми битом setuid. Весь код 4GL выполняется после того, как программа _progres отдала расширенные привилегии. Это является причиной того, что вы получаете ошибку 1136.

XIII.            Разделяемая память

92.      Мой сервер имеет 16 гигабайт памяти, но я не могу использовать буферный пул больше 2 гигабайт. Почему?

Потому что вы используете 32-битовую версию OpenEdge RDBMS. Никто не должен этого делать без хорошей причины, а таких причин мало. 64-битовые версии OpenEdge доступны для Linux, AIX, Solaris, HP-UX и Windows (для их использования вам нужны 64-битовые версии этих операционных систем).

Для всех 32-битовых версий OpenEdge на всех операционных системах имеется предел в 2 гигабайта (приблизительно) на общий объем разделяемой памяти, который может быть создан базой данных. Это ограничение накладывается на адресное пространство всех 32-разрядных процессов. Точное значение зависит от операционной системы и различных других факторов. Теоретически, 32-битовый процесс имеет максимальное полезное адресное пространства до 4 гигабайт, но вы не можете использовать его для данных полностью. Операционные системы используют часть адресного пространства для себя. Имеются также другие ограничения, накладываемые операционной системой. Объем адресного пространства, который доступен для разделяемой памяти, уменьшается из-за этих ограничений.

• 32-битовая операционная система Windows резервирует 2 GB адресного пространства для себя, оставляя 2 GB процессу. Имеется возможность изменить это ограничение, так что Windows зарезервирует только 1 гигабайт и выделит процессу 3 гигабайта, но это может вызвать неприятные побочные эффекты для всей системы. Вы не должны этого делать, даже если вы знаете, как. Вы были предупреждены. Из 2 GB, выделенных процессу, приблизительно 1,6 GB может быть использовано для разделяемой памяти.
• HP-UX выделяет в общей сложности приблизительно 1,7 GB разделяемой памяти для всей системы. В HP-UX имеется возможность, называющаяся «Memory Windows» (вы можете прочитать про это здесь: http://docs.hp.com/en/943/memwn1_4.pdf), которая предоставляет частичный и не особенно полезный обходной путь. Эта возможность трудна для использования, и только увеличивает предел для всей системы, но не предел для одной базы данных.
• В Linux, максимальный размер разделяемой памяти составляет приблизительно 2,7 GB.
• В AIX, 32-битовый процесс может прикрепить максимум 11 сегментов разделяемой памяти. Существует способ увеличить этот предел, используя переменную среды EXTSHM, но это приводит к ряду нежелательных побочных эффектов. Вы не должны использовать EXTSHM. Вы были предупреждены. До версии 10.1B, максимальный размер сегмента, используемый в OpenEdge RDBMS, составлял 128 мегабайт, эффективно ограничивая вас примерно 1,4 GB разделяемой памяти. Или меньше, если вы одновременно подключаете несколько баз данных в режиме self-serving, так как предел в 11 сегментов относится ко всему процессу.

Попытка превышения максимального числа сегментов для процесса приводит к сообщению об ошибке «(1175) Maximum number of shared-memory segments per process exceeded».

Некоторые или все из следующих элементов (иногда некоторые из них не используются) должны храниться в полезной части адресного пространства процесса:

• код и статические данные программы
• куча (heap) динамической памяти
• стеки потоков
• буферы файлов, дескрипторы файлов и т.д.
• UI-виджеты и связанные элементы
• сетевые подключения и соответствующие буферы
• разделяемые библиотеки (.dll)
• отображаемые на память файлы
• разделяемые библиотеки r-кода
• разделяемые сегменты памяти
• семафоры
• куча других вещей

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

Исполняемые файлы _mprosrv, _mprshut, _sqlsrv2, и _progres, _prowin являются отдельными программами, которые будут использовать одну и ту же область разделяемой памяти для данной базы данных, но не  так много кода. Каждая программа использует различные объемы стекового пространства и динамически размещаемых личных структур данных. Несколько экземпляров одного и того же исполняемого файла могут разделять собственный код и некоторые статические данные, а также области разделяемой памяти подключенных баз данных.

Заметим, что _mprosrv и _mprshut работают одновременно с единственной базой данных и разделяемой памятью, но _progres и _prowin могут подключаться к нескольким базам данных в режиме self-serving. В режиме self-serving, разделяемая память всех подключенных баз данных должна помещаться в адресное пространство. Когда _progres или _prowin подключается к базе данных через сетевое (socket) подключение, он не подключается к разделяемой памяти этой базы данных.

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

64-битовые версии исполняемых файлов OpenEdge не подвержены жестким пределам адресного пространства, описанным выше. Жестким по современным стандартам, конечно. На протяжении многих лет это не было проблемой. В Progress версии 5 максимальный размер буферного пула был лишь немного более 32 МБ. В 64-битовых системах вы можете значительно увеличить  параметр -B (предполагая, что вы имеете достаточно физической памяти). Это является основным преимуществом использования 64-битовых адресных пространств в системах баз данных. Это имеет свою цену: 64-битовый код немного медленнее и немного больше, чем 32-битовый для многих процессоров, но маловероятно, что вы заметите разницу.

Если вы запускаете базу данных под управлением 64-битового сервера базы данных OpenEdge, 32-битовые клиенты не смогут подключаться к серверу в режиме self-serving (так как структуры данных в разделяемой памяти не совместимы между 32-битовыми и 64-битовыми версиями OpenEdge), но смогут подключаться через сетевые (socket) подключения.

93.      Я увеличил значение -B и теперь я не могу подключиться к базе данных. Почему?

Потому что вы превысили предел 32-битового адресного пространства, который обсуждался в предыдущем вопросе, или 32-битовое адресное пространство вашего клиента слишком фрагментировано, что будет обсуждаться в следующем вопросе. Если вы видите сообщения об ошибках типа «(1175) Maximum number of shared-memory segments per process exceeded» или «(1176) The data space of the process is not enough for the shm segment», когда вы подключаетесь в режиме self-serving, то это наиболее вероятная причина.

94.      Какое значение следует установить для параметра -shmsegsize?

Вы должны использовать значение по умолчанию, если вы не столкнулись с проблемами. В версии 10.1B и более поздних изменился способ управления разделяемой памятью, что позволяет использовать меньшее число больших сегментов, и для 32-битового OpenEdge в некоторых операционных системах (например, AIX) общий объем доступной разделяемой памяти увеличился.

Когда используются большие сегменты, существует вероятность, что 32-разрядный  self-serving  клиент OpenEdge может быть не в состоянии подключиться к базе данных, поскольку адресное пространство клиента слишком фрагментировано, и не существует достаточно больших неиспользуемых блоков, доступных для сегментов общей памяти. Вы можете получить сообщение об ошибке типа «(1176) The data space of the process is not enough for the shm segment» или другое сообщение об ошибке, связанное с разделяемой памятью. В этом случае вы можете избежать проблемы, используя меньшее значение (например, 128) для параметра -shmsegsize.

Вы также можете избежать подобных проблем, используя 64-битовую версию OpenEdge RDBMS. В 64-битовых версиях OpenEdge вам обычно не требуется использовать конфигурационный параметр -shmsegsize.

95.      Какое значение является наилучшим для конфигурационного параметра -Mxs?

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

По умолчанию значение оценки требующегося объема динамически распределяемой разделяемой памяти равно (16384 + (nusers * 400)) байтов для 64-битовых версий OpenEdge и (16384 + (nusers * 300)) байтов для 32-битовых версий («nusers» здесь равно значению стартового параметра -n).

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

Если вы столкнулись с переполнением разделяемой памяти и получили сообщение об ошибке «Out of free shared memory. Use -Mxs to increase», то это может быть вызвано следующими причинами:

• Вы имеете больше обязательных для заполнения (mandatory) полей, чем позволяет оценка (для каждой таблицы, имеющей mandatory поля, требуется 48 байтов плюс 12 байтов на каждое mandatory поле);
• Произошла ошибка при вычислении размера разделяемой памяти;
• Произошло переполнение таблицы блокирования.

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

96.      Каковы пределы разделяемой памяти для 64-битовых версий OpenEdge?

Предполагая, что у вас имеется достаточно физической памяти и операционная система позволяет ее использовать, вы можете иметь до 256 сегментов разделяемой памяти, и каждый сегмент может иметь размер до 32 гигабайт. В операционных системах Linux и UNIX, параметр ядра SHMMAX определяет максимальный размер сегмента разделяемой памяти. Вам может потребоваться увеличить его, если он слишком мал. Если вы увеличиваете значение SHMMAX, вам также может потребоваться увеличить значение параметра SHMALL. Параметр SHMALL должен быть равен (SHMMAX / page-size)-страниц. Размер страницы зависит от системы, обычное значение равно 4096.

XIV.            Сеть

97.      Какой номер порта я должен использовать?

Простой ответ – любой порт (порты) выше 1023, который еще не занят какой-либо другой программой или службой. Порты 1023 и ниже первоначально предназначались для использования привилегированными программами и службами, и это было ошибочно придумано для обеспечения повышенной безопасности. Тем не менее, обычные пользователи не могут создавать службы (например, веб-сервер использует порт 80), которые используют эти порты. Хотя они могут подключаться к службам на этих портах. В UNIX, Linux и Windows для получения списка используемых в вашей системе портов вы можете использовать программу netstat. Если вы посмотрите на файл /etc/services, в нем вы найдете все виды назначений портов. Многие из них описывают порты, которые зарегистрированы и предназначены для различных продуктов и протоколов. Если вы не используете эти продукты или службы, то эти порты простаивают, и вы можете использовать их для чего-нибудь другого.

Когда вы запускаете базу данных такой командой:

proserve foo -S 5500

брокер базы данных будет использовать порт, указанный в параметре -S как номер порта подключения, на котором он прослушивает запросы на подключение. Но это не тот порт, который используется клиентами для обмена с серверами. Он используется только для установки соединения. Вы также можете использовать имя службы вместо номера порта. Имя службы – это просто символьное имя, определенное в файле /etc/services, которое назначено конкретному номеру порта. Назначение имен служб – облегчить переназначение портов без необходимости изменять большое количество кода, скриптов и команд. Просто добавьте соответствующие строки в файл определения служб, с комментарием, описывающим их использование.

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

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

proserve foo -S 5500 -minport 32000 -maxport 32500

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

98.      Может ли 32-битовый клиент OpenEdge работать с 64-битовым сервером OpenEdge?

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

99.      Какой ODBC драйвер мне нужен, 32-битовый или 64-битовый?

Ответ зависит от вашего ODBC приложения и от операционной системы, в которой оно работает. Если ваше приложение представляет собой 64-битовый исполняемый файл, тогда вы должны использовать 64-битовый ODBC драйвер. Если приложение представляет собой 32-битовый исполняемый файл, то вы должны использовать 32-битовый ODBC драйвер. Оба драйвера могут взаимодействовать с 32-битовой и с 64-битовой версиями OpenEdge RDBMS SQL server.

XV.            Прочее

Здесь приведены вопросы, которые не вошли в другие категории.

100.      Какой самый простой способ реализации аудита?

Используйте встроенную возможность Audit facility. Документация по этому вопросу может быть найдена в руководстве, озаглавленном «OpenEdge Getting Started: Core Business Services».

101.      Как определить codepage базы данных?

В 4GL функция DBCODEPAGE() возвращает имя кодовой страницы базы данных.

Виртуальная системная таблица _db также содержит это значение в поле _db._db‐xl-name.

102.      Правда ли, что Linux лучше, чем Windows?

Лучше для чего? Настольные системы Windows для клиентов весьма обычны. Сейчас больше людей используют системы Windows в качестве серверов баз данных, чем в прошлом. Если ваши сотрудники знакомы с Windows, но не с UNIX или Linux, то, вероятно, вы должны использовать Windows.

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

• Windows трудно управлять. GUI-инструменты могут быть красивыми, но они неэффективны и громоздки для администрирования.
• Windows имеет крайне примитивные средства для сценариев. Это делает автоматизацию всех обычных задач обслуживания и настройки базы данных более сложной, чем она могла бы быть.
• Хотя она и не совсем пустая, Windows не имеет многих утилит командной строки, часто используемых администраторами баз данных и системными администраторами в других операционных системах. Таких, как grep, head, tail, ssh, rsync, vi, bash, cron, vmstat, iostat, lsof, top, sar, dd, od, df, например.
• Системы Windows, как представляется, надо останавливать и перезагружать гораздо чаще, чем хотелось бы.
• Устранение многих бесполезных сервисов (например, индексатор, служба отчетов об ошибках, и многие другие), которые пожирают циклы процессора и память, а также всего остального, не нужного на сервере баз данных, занимает много времени.
• Обеспечение запуска процессов в правильное время и в правильном порядке при запуске системы является сложным. То же относится к завершению процессов при остановке системы.
• Windows является незрелой, непроверенной и несколько ненадежной.
• Реестр.
• Некоторые коммерческие утилиты резервного копирования для Windows могут влиять на операции с базой данных, если они настроены на закрытие программ, имеющих открытые файлы, а также, когда утилита копирует один или более файлов базы данных, база данных не может быть запущена, если эти файлы заблокированы программой копирования. Процессы базы данных могут получать фатальные ошибки ввода/вывода, если программа резервного копирования запускается при работающей базе данных. Вы должны сконфигурировать программы резервного копирования так, чтобы добавить файлы и каталоги баз данных в список исключений. Резервная копия, созданная с работающей базы данных, совершенно бесполезна, если она не создана программой онлайн-копирования OpenEdge.
• Ужас DLL.
• Windows требует использования активного антивирусного программного обеспечения. Такое программное обеспечение может серьезно мешать операциям с базой данных и ее использованию, и может оказывать пагубное влияние на производительность. Файлы базы данных обычно больше, чем прочие файлы, а некоторые антивирусные программы сканируют файлы каждый раз, когда они открываются. Когда файлы базы данных ошибочно будут помещены на карантин, вам это не понравится. Как минимум, вы должны настроить ваше антивирусное программное обеспечение, чтобы оно оставило ваши базы данных в покое, добавив их в список исключений.
• Если вы не сделаете что либо, чтобы это предотвратить, Windows update будет автоматически устанавливать патчи на работающей системе, останавливать и перезапускать ее без вашего ведома.
• Windows не имеет man-инструкций.
• Кэш файловой системы часто вызывает проблемы с производительностью и ошибки, когда он становится слишком большим и памяти становится недостаточно для программ.
• Windows работает только на процессорах Intel. IBM производит очень мощные серверы на основе процессоров POWER7, но на них Windows не работает.
• Подавляющее большинство инсталляций OpenEdge RDBMS, про которые мы знаем, что они используют большие базы данных (500 GB и более), работают под какими-либо UNIX-системами: Solaris, HP-UX, AIX, и т.д. и только очень немногие работают под Windows.

Все вышеизложенное – это наше мнение. Тут могут быть вещи, которые вас не волнуют или с которыми вы не согласны. Вы должны принять Ваше собственное решение относительно Windows.