Отсюда вопрос - где эффективнее всего использовать данное сжатие ? OLAP системы ? OLTP системы ?

[Vadik]

Цитата:

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

я немного разочарован - ожидал что производительность улучшится за счет сокращения объема операций ввода вывода

Vardecimal storage стоит рассматривать прежде всего как средство уменьшить использование дискового пространства при минимальных накладных расходах. Влияние на производительность стоит рассматривать скорее как побочный эффект, тем более что для разных систем оно будет разным. Да, IO теоретически может улучшиться, однако нагрузка на процессор увеличится хоть и незначительно, но гарантированно. Конечный результат будет зависеть от того, что в данный момент является узким местом системы.

Цитата:

Отсюда вопрос - где эффективнее всего использовать данное сжатие ? OLAP системы ? OLTP системы ?

Применять можно везде, так как накладные расходы невелики. В случае OLTP просто нужно учитывать некоторые моменты

Цитата:

Если применять к Аксапте, то для каких таблиц ?
Редко обновляемые большие таблицы (строки журналов, заказов, закупок) ?
Часто обновляемые большие таблицы с большим количеством числовых полей (InventSum)?

Ну, журналы я скорее предпочту чистить, нежели сжимать. Знаю, что выглядит немного радикально Знаю, что не всегда возможно (например, локализованные отчеты построенные на складских журналах)
INVENTSUM - скорее всего нет. Даже при использовании партий, палет и серийных номеров размер таблицы недостаточно велик, чтобы при включении VARDECIMAL получить хоть какую-то значимую экономию дискового пространства. Кроме того, при высокой частоте обновления (UPDATE) повышается вероятность того, что ранее "сжатая" запись должна "разжаться" (новое значение требует большей размерности по сравнению со старым) и на странице не свободного места, что ведет либо к расщеплению страницы, либо к появлению forwarded record (все это описано в whitepaper по ссылке, которую я привел)
INVENTTRANS, INVENTSETTLEMENT, LEDGERTRANS - тут выигрыш в занимаемом таблицей пространстве имеет место быть, какого-либо заметного влияния на производительность не ощутил (да и не ставил такой цели, если честно)

[mazzy]

Т.е. ты рекомендуешь скорее trans-таблицы.

1.
А стоит ли LedgerBalances*-таблицы?
Обычно они и большие, и содержат числовые данные, и в них много необновляемых чисел за старые периоды...

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

[Vadik]

Цитата:

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

Т.е. ты рекомендуешь скорее trans-таблицы

Перефразирую - большие таблицы

Цитата:

А стоит ли LedgerBalances*-таблицы?
Обычно они и большие, и содержат числовые данные, и в них много необновляемых чисел за старые периоды...

Я пока не встречался с ситуацией, когда остатки по GL представляли собой сколько-нибудь существенную долю от общего объема БД. Сжать - можно (за компанию с транзакционными таблицами), сожмется хорошо (в процентном отношении)

Цитата:

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

Это уже не VARDECIMAL, а DATA_COMPRESSION и соответственно следующая версия СУБД - SQL Server 2008. Стоит ли геморроиться - это уже решать DBA в каждом конкретном случае

[egorych]

Цитата:

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

Т.е. ты рекомендуешь скорее trans-таблицы...

Цитата:

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

Перефразирую - большие таблицы ..

Добавлю мое ИМХО - и еще из которых МНОГО читается. Много не в смысле часто, а много в смысле много записей.
Например у нас INVENTSETTLEMENT у нас ~50млн. Но читается из него по объему не много и в большинстве случаев по индексу - т.е. проблем не доставляет и в top запросов не фигурирует.
А вот SYSDATABASELOG подумываю сжать, ибо как что найти нужно, так IO начинает расти здорово! Ибо интексов ненастроешься на нее!