DAX 3.0 SP5FP2 - Архивация прошлых лет

[BokarevSS]

Расскажите пожалуйста, как мне можно от рабочей базы отделить прошлые года и положить их в отдельный архив, и при необходимости данные читались оттуда, а основная база включала в себя только текущий год - как, например, это реализовано в 1С Бухгалтерии.

[madm]

Может Вам подойдет партиционирование таблиц средствами СУБД?

[BokarevSS]

Может быть подойдет, но я плохо знаю каким образом это реализовать. Если Вам не трудно, расскажите.

[George Nordic]

Прочитайте про сегментирование. Раньше поддерживалось только на Oracle, но, кажется, в SQL 2005 тоже появилась такая возможность. Идея в том, что таблицу можно по некому признаку разбить на части - и, например, за последний год оставить на быстром диске, а остаток - убрать на обычный и медленный. Однако не работает при использовании локализованных отчетов.

Обсуждалось.


С Уважением,
Георгий

[ZVV]

Цитата:

Сообщение от George Nordic

Прочитайте про сегментирование. Раньше поддерживалось только на Oracle, но, кажется, в SQL 2005 тоже появилась такая возможность. Идея в том, что таблицу можно по некому признаку разбить на части - и, например, за последний год оставить на быстром диске, а остаток - убрать на обычный и медленный. Однако не работает при использовании локализованных отчетов.

Да, но не забывайте, что при этом подходе при любом изменении таблицы в Аксапте и её синхронизации таблица в БД будет пересоздана как несекционированная. (по крайней мере в Оракле так)
Мне кажется этот вариант не очень жизнеспособным, ну разве что если у вас абсолютно статичная система без малейших модификаций...

[madm]

Вкраце коллеги уже написали, дополню: Partitioned Tables and Indexes in SQL Server 2005


Какая у Вас СУБД используется? Какой размер БД? Вообще как пришли к решению что надо разделить данные?

[BokarevSS]

СУБД - Microsoft SQL Server 2000 Standart.
Размер БД - 23Гб.
С ростом базы система работает все медленнее и медленее, и в добавок мы делаем ежедневные бэкапы и каждый день бэкапить старые года, по сути одно и тоже, бессмысленная трата дискового пространства. Один бэкап = 3,5Гб.

[MironovI]

По поводу бэкапов просто - делайте полные бэкапы еженедельно, а ежедневно - дифференциальные.
По поводу скорости - секционирование не изменит размер базы данных и не даст коренного прироста скорости. 23 гигабайта - это еще не критичный размер для базы - либо у вас проблемы в железе (память, диски), либо если допустить что с железом все нормально - у вас были доработки, которые плохо масштабируются.

[fed]

В общем - на мой взгляд на 3ей версии это не решить в приниципе. Для DAX2009 поддерживается back-end partitioning (хотя сам не проверял - только слайды презентации смотрел). Коротко говоря - если ты ручками отпартиционировал таблицу за пределами аксапты, то при дальнейших синхронизациях это партиционирование будет сохраняться.

[Vadik]

Цитата:

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

Размер БД - 23Гб. С ростом базы система работает все медленнее и медленее

Ну вообще 23Гб это imho не совсем тот размер, с которого стоит partitioning-ом заморачиваться. Идея секционирования по дате тоже весьма сомнительная, так как довольно небольшой процент запросов получит с этого хоть какие-то бенефиты. Если повезет (или неповезет, это кому как) и компаний много, можно отсекционироваться по DATAAREAID, скрипт уже демонстрировался

Цитата:

мы делаем ежедневные бэкапы и каждый день бэкапить старые года, по сути одно и тоже, бессмысленная трата дискового пространства. Один бэкап = 3,5Гб

Отдает эконимией на спичках Бэкапьтесь больше и чаще

Цитата:

СУБД - Microsoft SQL Server 2000 Standart

Учитывая это, про секционирование можно забыть - нет его в 2000

Цитата:

В общем - на мой взгляд на 3ей версии это не решить в приниципе

Отчего же. Для приложения это прозрачно

Цитата:

Да, но не забывайте, что при этом подходе при любом изменении таблицы в Аксапте и её синхронизации таблица в БД будет пересоздана как несекционированная. (по крайней мере в Оракле так)
Мне кажется этот вариант не очень жизнеспособным, ну разве что если у вас абсолютно статичная система без малейших модификаций...

Всего-то нужен job, который секционирует то, что "секционировали, секционировали да не высекционировали". Скрипт, приведенный выше, это умеет
BokarevSS, я бы на Вашем месте

• устроил ревизию модификаций
• посмотрел сюда

(именно в такой последовательности)

[ZVV]

Цитата:

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

Всего-то нужен job, который секционирует то, что "секционировали, секционировали да не высекционировали"...

Безусловно, можно, но всё это будет отнимать дополнительное время, на синхронизацию, на "пересинхронизацию"...
Как говорится, "можно сделать всё - вопрос времени и целесообразности".

[blokva]

Немного поделюсь опытом:
(Огромное спасибо Torin за помощь на начальном этапе)
1. база ~200 гиг.
2. партицирование делалось по дате только для огромных таблиц
3. при партицировании, главное условие: значимое поле (дата в моем случае) должно входить в кластерный индекс (что косвенно увеличивает размер базы)
4. приведенный скрипт by Torin, не подошел, т.к. я не все таблицы партицировал.
5. я создал отдельные filegroup, files, функцию и схему партицирования по полю типа "дата"
6. для каждой таблицы (12 штук) был отдельный скрипт
7. вручную удалял кластерный индекс для таблицы
8. добавлял в кластерный индекс поле "дата" если это требовалось
9. запускал скрипт из п.6.
10. затем filegroup делал readonly и средствами NTFS сжимал фалы этой группы. (мне хотелось именно это сделать)

В итоге база стала 110 гиг из них 20 занимает на диске (реально 60) созданная партиция.
Проверял отчеты по данным таблицам, работают без проблемм и снижения производительности не заметил.
Конечно это не серьезное исследование, но кое какие выводы сделал, например, то что в моем случае, никакие структурные изменения для партицированных таблиц невозможны (ибо readonly)

[fed]

Ну и чтобы завершить тему рекомендую зайти по ссылке:
https://emea.msconvergence.com/Publi...?categories=ax и внимательно посмотреть на презентацию AX10.
На всякий случай - дисклеймер: Страница найдена гуглом, никакого разглашения инсайда, никого не трогаю - починяю примус

[Vadik]

Цитата:

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

Немного поделюсь опытом:
..
10. затем filegroup делал readonly и средствами NTFS сжимал фалы этой группы. (мне хотелось именно это сделать)
В итоге база стала 110 гиг из них 20 занимает на диске (реально 60)

На всякий случай.. (хорошо что ветку подняли, сразу не ответил, потом забыл)
SQL Server databases not supported on compressed volumes

[blokva]

Цитата:

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

На всякий случай.. (хорошо что ветку подняли, сразу не ответил, потом забыл)
SQL Server databases not supported on compressed volumes

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

[Poleax]

Цитата:

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

Ну и чтобы завершить тему рекомендую зайти по ссылке:
https://emea.msconvergence.com/Publi...?categories=ax и внимательно посмотреть на презентацию AX10.
На всякий случай - дисклеймер: Страница найдена гуглом, никакого разглашения инсайда, никого не трогаю - починяю примус

Как просмотреть AX10 ? Не нахожу линки? Какой доступ нужен на это дело?

[fed]

Ой - извиняюсь- неверно выразился. Речь шла о том чтобы посмотреть на тему презентации и сделать выводы. Например о том что, вероятно, механизм архивации данных для аксы все-таки разрабатывается в Микрософте

[EVGL]

Цитата:

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

Ой - извиняюсь- неверно выразился. Речь шла о том чтобы посмотреть на тему презентации и сделать выводы. Например о том что, вероятно, механизм архивации данных для аксы все-таки разрабатывается в Микрософте

И обещания его выпуска исправно переносятся из версии в версию.

[ZVV]

Цитата:

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

И обещания его выпуска исправно переносятся из версии в версию.

В 2.5 была такая вещь уже как Axapta Oracle Company partitioning option...

Цитата:

Сообщение от Microsoft Business Solutions-Axapta V3.0 Databases Advanced

Partitioning of data possible based on company (beginning in
version 2.5 and only for version 3.0 for those database and
applications that have been upgraded from version 2.5).

....

Partitioning support has been turned off in version 3.0 since it did not have
the expected effect.

[Logger]

Цитата:

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

Partitioning support has been turned off in version 3.0 since it did not have
the expected effect.

Чо-то сомнительно... Скорее всего что-то другое просаживало производительность.