Конфигурирование серверов БД на платформе Sun
Оценить
(0 голоса)
Хотя кэш страниц файловой системы UNIX может оказаться достаточно эффективным для операций чтения, буферный кэш БД адекватного размера реализует более эффективную стратегию кэширования, чем та, которую обеспечивает кэш второго уровня, предоставляемый операционной системой. Аналогичное утверждение справедливо и для кэширования операций записи. Иногда в системах с большими объемами памяти может потребоваться 64-разрядная СУБД, чтобы установить буферные кэши соответствующего размера. •             Некоторые приложения, такие как большие пакетные задания, от кэширования страниц памяти получают небольшие выгоды или вообще не получают никаких, к тому же применение UFS означает, что каждая страница памяти должна быть занесена в кэш UNIX прежде, чем она сможет быть использована.…
Оценить
(0 голоса)
Операции записи в журнал часто имеют размер более 8 Кбайт. Тем не менее, при использовании журналов баз данных, размещаемых в файловых системах UFS, большие записи разбиваются на блоки размером 8 Кбайт; это побочный эффект того факта, что файлы открываются с флагом 0_DSYNC. Низкоуровневые устройства кроме того обеспечивают несколько большее количество дисковой памяти, пригодной для использования. Разделы файловой системы UFS сопровождаются накладными расходами за счет информации суперблока, индексных дескрипторов и в части обеспечения производительности; обычно резервируют еще примерно 1% (10% в более старых версиях Solaris) памяти, доступной только для суперпользователя. Иногда файлы UFS могут продемонстрировать даже более высокую производительность, чем низкоуровневые…
Оценить
(0 голоса)
Если принято решение размещать файлы БД в файловых системах, вы можете выбрать один из нескольких альтернативных вариантов реализации в стиле UFS: •             Стандартная UFS (в том виде, как она реализована операционной системой Solaris). Все операции доступа к страницам UFS управляются через страничный кэш файловой системы Solaris. Характеристики файлов UFS были рассмотрены в предыдущем разделе. •             Прямой ввод/вывод. Начиная с Solaris 2.6, файловые системы могут быть смонтированы с опцией forcedirectio. В таких файловых системах операции доступа к файлам на дисках будут обходить страничный кэш файловой системы Solaris. Однако КАЮ не используется в том случае, когда асинхронный ввод/ вывод осуществляется с файлами,…
Оценить
(0 голоса)
Для достижения оптимальной производительности следует использовать следующее (в порядке предпочтения): 1.            Низкоуровневые устройства. 2.            Прямой ввод/вывод, начиная с Solaris 8 I/01, или VxFS с опцией Quick I/O. 3.            Прямой ввод/вывод операционной системы, начиная с Solaris 2.6. 4.            Файловую систему UFS. Если для баз данных применяются файлы UFS, важно избегать использования нескольких очень больших файлов, распределенных между многочисленными дисками. Такое использование может привести к конфликту блокировок чтения/записи на уровне индексных дескрипторов из-за единственной блокировки механизма записи UFS, речь о которой шла ранее в настоящей главе. Лучше использовать множество файлов. даже если они будут размещены в одной и той же файловой системе.…
Оценить
(0 голоса)
Как было показано ранее, понятие расслоения (расщепления) данных, также известное как RAID 0, относится к практике распределения данных между несколькими дисками с использованием распределения по типу "карусели". Ширина слоя представляет собой количество данных, которые система размещает на каждом диске перед тем. как переходить к следующему диску. Например, если 10 Мбайт информации распределяются методом расслоения между восьмью дисками при ширине слоя данных, равной 128 Кбайт, то первые 128 Кбайт будут записаны на диск номер один, вторые 128 Кбайт - на диск номер два и т.д. После того, как восьмая порция в 128 Кбайт будет записана на диск номер восемь, девятая опять…
Оценить
(0 голоса)
Понять преимущества технологии расслоения больших операций ввода/вывода между несколькими дисками достаточно просто. К сожалению, некоторые люди думают, что та же самая логика рассуждений применима и к небольшим операциям ввода/вывода. Например, почему бы для того, чтобы ускорить выполнение операций чтения по 4 Кбайт, ни разделить каждую страницу размером 4 Кбайт между четырьмя дисками (по 1 Кбайт каждому)? Представьте себе, что вы живете в деревне, в которой водоснабжение осуществляется из четырех колодцев. Если срочно необходимо много воды, например, когда горит чей-то дом, то имеет смысл послать людей с ведрами ко всем четырем колодцам одновременно. С другой стороны, если нужно наполнить водой маленькую…
Оценить
(0 голоса)
Как было показано ранее, считывать I Мбайт данных с восьми дисков одновременно намного быстрее, чем с единственного диска. Однако теория часто бывает более прямолинейна, чем реальная жизнь, и этот простой пример быстро становится сложным в реальной жизни. Редко бывает так, что на сервере выполняется только одни прикладной процесс. А что произойдет, если восемь процессов прикладных программ будут считывать I Мбайт данных в одно и то же время? Какой вариант лучше: когда каждое приложение выполняет чтение с отдельного диска без взаимного влияния или когда каждое приложение для того, чтобы завершить операцию чтения, конкурирует за доступ ко всем восьми дискам одновременно? И…
Оценить
(0 голоса)
Следует отметить, что расслоение может привести к большему количеству операций доступа к дискам, чем предполагается. Например, если используется ширина слоя данных, равная 128 Кбайт, и если начальная точка операции чтения не идеально совпадает с начальной точкой слоя данных на диске, то операция чтения размером 128 Кбайт потребует двух операций доступа к дискам вместо одной. Если операция чтения начинается посередине слоя данных, то половина данных будет считываться со слоя на первом диске, а другая половина - со слоя на следующем диске. Точно так же чтение I Мбайт данных с дискового слоя, который имеет ширину, равную 128 Кбайт, может потребовать девять операций…
Оценить
(0 голоса)
Учитывая, что целесообразно расслаивать данные всех типов между всеми дисками, должен ли каждый файл БД расщепляться по каждому доступному диску? Ответ на этот вопрос зависит от количества дисков. Если вы располагаете всего несколькими дисками (например, не более 20), то имеет смысл расщеплять каждый файл БД между всеми дисками. Однако расслоение каждого файла по сотне дисков, вероятно, будет избыточным. Данные всех типов могут расщепляться по всем дискам, но при этом необязательно расслаивать каждый файл БД по всем дискам. Если, например, табличное пространство клиента имеет пять файлов, содержащих одинаковое количество данных, то каждый из этих файлов мог бы быть разделен между 20…
Оценить
(0 голоса)
В предыдущих рассуждениях о технологии расслоения предполагалось, что каждый диск индивидуально адресуется операционной системой. Для обозначения дисков такого типа часто употребляется аббревиатура JBODs (Just a Bunch of Disks -группа жестких дисков, но без использования RAID). Однако многие диски конфигурируются в дисковые массивы хранения данных, в которых отдельные диски непосредственно не доступны. Примерами такого типа массивов являются Sun StorEdge ТЗ, АЮОО и более старые модели А3000 и А3500. Вместо представления индивидуальных дисков, эти массивы хранения данных используют LUNs (Logical Unit Numbers - логические номера устройств). Интеллектуальные контроллеры дисковых массивов хранения данных отображают LUNs в физические диски, входящие в данный массив. LUNs…