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

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-битных целых чисел переменной длины и могут содержать тот же диапазон значений.