Перенос таблиц DAX в новую файловую группу

[gkochkin]

Коллеги, добрый день!
Для повышения производительности вынесли две таблички на быстрые, менее нагруженные диски, перестроив индексы с указанием новой файловой группы средствами SQL.
AX 2009, SQL Server 2008 R2
Подскажите, Аксапта при синхронизации не вернет ли случаем таблички наши на старое место?

[mazzy]

Цитата:

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

Подскажите, Аксапта при синхронизации не вернет ли случаем таблички наши на старое место?

может.
аксапта может выполнить синхронизацию разными способами.
1. sql command: alter table, alter index, alter...
2. через создание новой вспомогательной таблицы
2.1. создает новую таблицу с служебным именем
2.2. переносит все данных в нее
2.3. удаляет старую таблицу
2.4. переименовывает новую


если у sql команд еще есть шанс не затронуть файловую группу
то синхронизация через вспомогательную таблицу будет плевать на игнорировать ваши настройки и будет использовать дефолтную файловую группу.

[Logger]

Попробуйте на тестовой табличке.
Еще лучше прописать для вашей таблички тейблспейс в sqlStorage. Для нее формочка была sysSqlAdmin или sysSqlSetup

[S.Kuskov]

С синхронизацией можно бороться. Запрет синхронизации объекта АОТ

[Vadik]

Цитата:

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

Коллеги, добрый день!
Для повышения производительности вынесли две таблички на быстрые, менее нагруженные диски

Ну а самое-то главное, как тестировали производительность ДО и ПОСЛЕ, на каких операциях и данных, и какой прирост (и есть ли) ? Сравнивали ли с другими вариантами? Или просто делаем, потому что можем (традиционый админский зуд) ?

Я почему спрашиваю - если у нас был массив на M шпинделей и мы переносим часть данных на новый (N), теоретический максимум в N шпинделей для нашей "важной" таблицы может оказаться меньше чем M+N минус шпиндели занятые обслуживанием "остальной Аксапты". Т.е. железо и нагрузку мы начинаем балансировать в ручном режиме через конфигурацию, что есть не сильно гибко так как можно не угадать либо характер доступа поменяется через полгода. СХД нагрузку равномерно размажет по всем доступным ресурсам

Что однозначно имеет смысл разносить, так это файлы с разным характером доступа - лог (последовательная запись), данные (в основном случайное чтение и запись) и tempdb, и массивы организовывать соответственно нагрузке. Растаскивание таблиц по массивам в системе с тысячами таблиц - это уже задача для ценителя и СХД размеров дисков так хотя бы в полсотни.

Все - мое личное мнение, разумеется