Kru,
например, контроль за дисковым пространством, которое занимает эта таблица.
Why use segments?

KruSQLMantisKru,
например, контроль за дисковым пространством, которое занимает эта таблица.
Why use segments?

Но ведь одного сегмента вполне достаточно?
Зачем второй?

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

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

KruВсем большое спасибо.
Тоже такой вопросик - могут ли девайсы входящие в сегмент находиться на дисках принадлежащих разным машинам (входящих в кластер).

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

komrad
мнээ, это зачем? чтобы внести элемент неопределенности (плюс доп. задержка на чтение/запись) под названием "сеть" ?

Вот, что это, только что, было? Наезд? )

Честно скажу, я не особо баловался сегментами.
Однако, в плане контроля за пространством, мне представляется вполне жизнеспособным следующий вариант.
Не секрет что во многих и по разному спроектированных базах есть всего несколько таблиц, которые наибольшим образом влияют на прирост данных. Такие таблицы, как правило, с некой периодичностью подвергаются очистке (старые данные удаляются, агрегируются...etc).
Перенеся подобную таблицу на отдельные сегменты с заранее определенным размером (размер девайса), мы получаем следующее:
1) Повесить диспечер порогов на сегмент что позволит реагировать на превышение определенных порогов событиями от нотификации до автоматической очистки/агрегации.
2) Даже если эта таблица займет все отведенное ей пространство, операции с другими таблицами в базе будут работать.
3) Влияние всевозможных group, order, join etc по этой таблице на базу tempdb можно контролировать пунктом 1.
4) Ну и конечно повышение производительности за счет разнесения данных и некластерных индексов

0rcSQLMantis,
как мне кажется, в дисковых презентациях через SAN и создании девайсов через lvm все эти изыски просто ничего не дадут в плане производительности
(контроль места и пороги не считаем)

Не дадут.
Но ведь это не изыски а насущная потребность.
SAN используют далеко не все.

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

Storage Area Network.
Выиграша не будет по причине манипулирования системой не физическими дисками а логическими томами , которые как правило уже "размазаны" по рейду. То есть с точки зрения I/O там и так все уже должно быть оптимизированно, хоть и в общем виде.

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


Не понял, что значит индексы разместить на более быстрой и мощной машине ?
Индексы можно разместить на отдельном сегменте, что с точки зрения повышения производительности при применении SAN скорей всего не оправдано.
Хотя, теоретически, если на сервер придет два fibre channel, по ним придут два логических тома, которые, каким то чудесным образом, есть суть двух разных физических томов ?

А так вообще для больших таблиц для которых выполняются аггрегированные запросы надо еще о tempdb не забыть позаботиться :)

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

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

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

Это должно дать прирост производительности.

Но это в теории, а хотелось бы узнать, что существует на практике.



Заранее большое спасибо.

На практике все храниться на SAN, сервера в кластере, диски или совместно используются или елозят между серверами.
Бывает так что люди не заморачиваются и даже сам ASE с таких дисков запускают.
На все это хозяйство еще и backup натравливается.
В общем SAN это удобно :)