Распределение базы по разным дисковым массивам

[SHiSHok]

Ax3.0sp3 vs MS SQL2ksp4
Имеется 2 дисковых массива:
1) RAID 10 (6 дисков)
2) RAID 10 (6 диска)
Сейчас база находится на рейд 1, лог на ред 2. Планирую перенести часть данных с рейда 1 на рейд 2 (filegroups). Функционал:финансы + логистика + торговля (финционал модифицирован но идеология осталась базовая).
"Оперативный" набор данных хранится сиквелом в памяти и дисковая подсистема интенсивно используется во время различно рода отчетов (потому как за частую это просмотр *Trans таблиц).
Существует 3 подхода:
1) разносить данные с индексами
2) разнести стержневые таблицы (например inventTrans - inventDim)
3) комбинировать 1 и 2 подходы.
Имеются ли рекомендации относительно распределения данных для достижения максимальной эффективности использования 2 массивов?

[glibs]

Я бы попробовал просто два файла данных создать на разных массивах (аналог JBOID, но из RAID массивов). И пусть СУБД сама решает что куда писать.

[SHiSHok]

Цитата:

Сообщение от glibs

Я бы попробовал просто два файла данных создать на разных массивах (аналог JBOID, но из RAID массивов). И пусть СУБД сама решает что куда писать.

мне кажется хаотичное распределение страниц по массивам на увеличении производительности никак не скажется. Хотя это можно рассматривать как вариант объединения 2х массивов (можно даже программный raid 0 сделать из 2х физических массивов)

[ZVV]

Про Oracle, но всё-таки...

[SHiSHok]

Цитата:

Сообщение от ZVV

Про Oracle, но всё-таки...

Почерпнул знание о том что разнесение индексов с данными по разным массивам не принципиально для исполнения запроса, так как в транзакции индекс и данные читаются последовательно.
Считаю что разнесение имеет смысл только с целью оптимизации I/O с массива, так как индекс содержит гораздо меньше полей и одна запись индекса имеет гораздо меньший размер чем строка данных. Соответственно чтение одного диапазона индекса и данных породит разный объем I/O, поэтому имеет смысл индекс располагать на массиве с меньшей пропускной способностью (если таковой имеется).

Дальше, думаю, надо рассматривать схему данных акс, для оптимизации исполнения запросов. В первую очередь выносить на другой массив "подключаемые" таблицы, которые чаще участвуют в связках нежели самостоятельно:
1) Для торговли и логистики имеет место быть часто встречающаяся следующая связка: (*trans, *line) -> InventDim -> Invent*. Соответственно InventDim и (*line, *trans , invent*) разносятся по разным массивам.
2) можно разнести DocuRef с DocuValue.

есть еще идеи?

[Logger]

sysDataBaseLog отдельно вынести.

[Raven Melancholic]

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

[AndyD]

2 Raven Melancholic

Для этого можно воспользоваться формой SysSqlSetup (доступ к ней есть через форму SQL Администрирование, но он включается только для ORACLE, хотя использовать можно и для MS SQL).

Только для работы с SQL2005 надо ее слегка доработать
В метод sqlServerInit() надо добавить

...
    resultSet = statement.executeQuery('select groupname from sysfilegroups');
    while(resultSet.next())
    {
        segmentName = resultSet.getString(1);
        sqlSegment.add(segmentName);
    }
   sqlSegment.setDropSize();
}

Изменение файловых групп надо делать в этой форме. После этого запускать синхронизацию в AOT

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

PS
В этой форме список таблиц выводится в порядке следования их ID. Для настройки неудобно, по-этому сделал сортировку по наименованию

void fillTables()
{
    int             tableCounter;
    dictTable       dictTable;
    Set             set = new Set(Types::String);
    SetEnumerator   tableEnum;

    tableList.lock();
    for(tableCounter = dictionary.tableNext(0); tableCounter > 0; tableCounter = dictionary.tableNext(tableCounter))
    {
        dictTable = new DictTable(tableCounter);
        if((!dictTable.isTmp()) && (!dictTable.isMap()))
            set.add(dictTable.name());
//            tableList.add(dictTable.name());
    }
    tableEnum = set.getEnumerator();
    while (tableEnum.moveNext())
    {
        tableList.add(tableEnum.current());
    }
    tableList.unLock(true);
}

[SHiSHok]

Цитата:

Сообщение от Raven Melancholic

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

изменил файл.группу для индексов -> добавил поле -> синхронизировал -> удалил поле -> синхронизировал := файловые группы у индексов остались.
удалось вернуть индексы в прежнюю файловую группу в SQL Администрирование - переиндексация (и то index с типом Primary Key остался в новой группе)
а какие версии Ax и сиквела у Вас?

[SHiSHok]

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

[Alexius]

Цитата:

Сообщение от AndyD

Кластерные индексы хранятся вместе с данными ...

Кластерные индексы являются самими данными, только отсортированными.
На мой взгляд некорректно разделять эти два понятия

[Alexius]

Цитата:

Сообщение от SHiSHok

Имеются ли рекомендации относительно распределения данных для достижения максимальной эффективности использования 2 массивов?

Прирост производительности, скорее всего, будет минимальным, т.к. общая производительность дисковой подсистемы не увеличится. Совмещение на одном массиве файлов БД и логов транзакций не желательно, запись в логи производится on-line, а в БД отложенно. Занимался подобным разделением с 4-мя массивами в конечном варианте, но основной целью было увеличения дискового пространства. Единственное удобство - возможность мониторить загрузку дисков по выделенным табличкам в Performance Monitor

[SHiSHok]

про лог согласен, так что будет скорее всего:
канал 1

• raid 10 (6 disks) : DATA1

канал 2

• raid 1 (2 disk) : LOG
• raid 10 (4 disks) : DATA2

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

[Raven Melancholic]

Цитата:

Для этого можно воспользоваться формой SysSqlSetup (доступ к ней есть через форму SQL Администрирование, но он включается только для ORACLE, хотя использовать можно и для MS SQL).

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

Цитата:

изменил файл.группу для индексов -> добавил поле -> синхронизировал -> удалил поле -> синхронизировал...

Странно. Мы это пробовали на DAX3.0 SP3, MS SQL2ksp5 (кернел Аксы не помню, но еще до появления возможностей работы с MS SQL2005). Синхронизация изменений убивала вынос индексов на отдельные тома.

[Wamr]

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

Если решите переходить на 2005, то для него рекомендуют tempdb выносить на отдельный диск.

[SHiSHok]

Цитата:

Сообщение от Wamr

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

Если решите переходить на 2005, то для него рекомендуют tempdb выносить на отдельный диск.

tempDB для любой редакции лучше на отдельном диске делать + количество файлов по количеству процов ( подробнее http://support.microsoft.com/kb/328551 ).

[Vadik]

Цитата:

Сообщение от SHiSHok

есть еще идеи?

Давайте сначала определимся с целью -
а) "распределение ради распределения". Тут число вариантов стремится к бесконечности
б) "отделить финансы от логистики". Да, можно. Только много ли операций в финансах, сильно напряшающих ХД? Знаю пару типа финансовых отчетов (с использованием корреспонденции), не более. Т.о., если просто "все поделить", половина ХД будет нагружена логистикой, половина - простаивать
в) "разнести ради производительности". Интересная тема. Хочу увидеть реально работающую схему. Хочу увидеть сравнение с цифрами "до и после". Еще больше хочу увидеть методику сравнения. Пока видел только теории

Цитата:

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

Если мы знаем, что логистике нужно много IO, imho не очень логично насильно ее "зажимать"

Сам там, где возможно, стараюсь следовать принципу KISS principle

[SHiSHok]

Цитата:

Сообщение от Vadik

Давайте сначала определимся с целью -

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

[Vadik]

Цитата:

Сообщение от SHiSHok

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

Единственный на мой взгляд способ оптимально утилизировать весь ресурс (все шпиндели) - это как раз "не заморачиваться" и свалить все в одну файловую группу
Если кто-то сможет предложить схему разбиения, которая будет работать шустрее, чем одна файловая группа - welcome, только, по возможности - с цифрами
Если свободное место на сторадже поджимает, можно подумать насчет миграции на raid5. Если ХД относительно новая (выпущена в этом веке) - вполне может справиться, мы на примерно того же размера БД гоняем на CX300 без особых проблем

Цитата:

Методику сравнения вижу только в сравнении показательных запросов на холодном кэше

А транзакции в системе магическим образом возникают - т.е. OLTP нагрузка как таковая отсутствует ?

[SHiSHok]

Цитата:

Сообщение от Vadik

Единственный на мой взгляд способ оптимально утилизировать весь ресурс (все шпиндели) - это как раз "не заморачиваться" и свалить все в одну файловую группу

в одну не выйдет, как минимум 2 (на 1 массив и на другой). или предлагаешь JBOD-массив сделать виндовыми средствами? как по мне так лучше пусть 2 массива будет.

Цитата:

Сообщение от Vadik

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

Боюсь что схема разбиения (имеется в виду потаблично) во многом будет зависеть от специфики работы Ax в конкретном предприятии. А 5-го рейда побаиваюсь на OLTP системе (я не знаю кто такой CX300).

Цитата:

Сообщение от Vadik

А транзакции в системе магическим образом возникают - т.е. OLTP нагрузка как таковая отсутствует ?

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