Очистка больших таблиц DAX

[ppson]

Цитата:

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

Может, какие-то ресурсы, ссылки и тп по очистке таблиц подскажете?

Не чистите таблица DAX, кроме тех которые рекомендует MS.
все это от лукавого
В случае эпического катаклизма люди из бизнеса придут за ответами именно к вам.

[db]

Цитата:

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

330 ГБ не так уж и много. Если вернуться к начальной постановке вопроса - что будет, если ничего не делать?

поддерживаю
330 гб это не то что не очень много это вообще ниочем
Проблема не в гигабайтах, а в неоптимальных запросах dax к бд, неоптимальных индексах, неправильных настройках самой бд, несоответсвующим задачам оборудовании, отсутствии здравого смысла в настройках журнала базы данных в частности и здравого смысла применительно к настройкам системы вообще , кривых доработках и т.д. и т.п.

ищите узкие места, думайте, оптимизируйте. резать на таких объемах проводки это всё равно что отрезать голову при головной боли

[Logger]

Сказать много или мало можно только посмотрев на железо на котором все это крутится.

[ivas]

Цитата:

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

Объем - порядка 330 ГБ.
Если честно, не совсем понимаю - пересесть в новую базу и что?
Над новой компанией точно не думали..

330гб это не много, объем таблицы InventTrans на производительность влияет косвенно (если конечно вы не суммируете проводки например в дисплей методах ).
Интересно было бы посмотреть объем других таблиц например InventDim, InventSum, Cust/Vend/Trans/TransOpen. А в целом нужно конечно видеть хотя бы топ 25 тяжелых запросов и знать конфигурацию SQL серверов.

Ах, да, чистить быстрее всего с помощью TRUNCATE TABLE https://msdn.microsoft.com/ru-ru/library/ms177570.aspx

[eugene egorov]

Цитата:

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

Ах, да, чистить быстрее всего с помощью TRUNCATE TABLE https://msdn.microsoft.com/ru-ru/library/ms177570.aspx

DROP DATABASE [IF EXISTS] db_name гораздо гораздее

[ivas]

Цитата:

Сообщение от eugene egorov

DROP DATABASE [IF EXISTS] db_name гораздо гораздее

Тоже неплохой вариант по производительности но после команды DROP TABLE/DATABASE теряется структура таблицы, а отчистка подразумевает удаление только данных

[Alexius]

Цитата:

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

330 гб это не то что не очень много это вообще ниочем
Проблема не в гигабайтах, а в неоптимальных запросах dax к бд, неоптимальных индексах, неправильных настройках самой бд, несоответсвующим задачам оборудовании, отсутствии здравого смысла в настройках журнала базы данных в частности и здравого смысла применительно к настройкам системы вообще , кривых доработках и т.д. и т.п.

С оптимизацией запросов понятно, но вот обслуживание большой БД при отсутствии приличного технологического окна может превратится в кошмар, о чем мне кажется и писал :

Цитата:

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

InventTrans у нас очень большая, такая, что с ней практически невозможно проводиться какие-то операции (реиндексация, секционирование и т.д.).

[vmoskalenko]

Ко мне приходили слухи, что IDMF будет кусочком нового варианта Миграции данных при апгрейде с AX2012 на AX7.

Т.е. IDMF режет все транзакции в AX2012, а потом DMF экспортит/имопртит оставшееся в AX7.

Но опять же, это все слухи. Посмотрим что нам предложат для Апгрейда данных на AX7.

[ALES]

Цитата:

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

Проблема не в гигабайтах,..

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

[Владимир Максимов]

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

Относительно приемлемое решение:

Разделить базу данных на 2: рабочая и архивная часть.

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

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

Размер таблиц

330 ГБ на одну таблицу - это много! Не с точки зрения оптимизации запросов, а с точки зрения администрирования таких таблиц. Создание полей, создание индексов, переиндексация, создание backup - все это будет чудовищно тормозить на таких размерах

----------------

Только что обратил внимание, что тема двухмесячной давности. Но снобизм в отношении размеров - постоянно возникающий мотив... Как только кто-то заикнется, что размер большой и приведет размер таблицы/базы в байтах, так тут же кто-то "встрянет" на тему, что это немного...

[ALES]

Цитата:

Сообщение от Владимир Максимов

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

Да, да.. это надо кому-то "продать" как яркое подтверждение "зачем "дорогой" консалтинг кормить, ведь и так все очень просто и быстро решается без анализа" :
1. всех "старых добрых проверенных" контрагентов "в архив"
2. "постоянный ассортимент" номенклатур "в архив"
3. за два года так и не "списанные" полностью проводки (те же приходы на склад) "в топку" и пусть главбух возрадуется "излишкам" инвентаризации (большая часть которых после такого решения и до "первого пересчета" физически не доживет)
4. все формы и отчеты не должны из архива данные выводить
...
В итоге "исправляйте... это же ошибки... работать же нельзя... да вы нас не правильно поняли... очевидно же не вообще все zzzzz таблиц "в архив"... конечно же не все "возращенное" из архива должно обратно "при очередном архивировании" помещаться, раз мы это обратно вернули значит нам оно нужно.. пользователи не будут "смотреть и возвращать только действительно нужное" из архива.. есть же какой-то более дешевый "аппаратный" архив на уровне СУБД который сам все автоматически.. а докажите, что задавали вопросы.. мы не помним, что разговор был.. вы же профессионалы должны были.. какие такие доп. требования.. бюджет фиксирован... все консультанты непоймикогопонабиралинаработупродаютвтридорога )) и т.д."

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