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

[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.

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

[Vadik]

Цитата:

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

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

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

Цитата:

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

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

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

[Logger]

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

[Raven Melancholic]

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

[SHiSHok]

Цитата:

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

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

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

[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);
}

[Alexius]

Цитата:

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

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

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

[SHiSHok]

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

[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 ).