12.04.2017, 09:25 | #21 |
Участник
|
Не чистите таблица DAX, кроме тех которые рекомендует MS.
все это от лукавого В случае эпического катаклизма люди из бизнеса придут за ответами именно к вам.
__________________
|
|
12.04.2017, 22:52 | #22 |
Роман Долгополов (RDOL)
|
Цитата:
330 гб это не то что не очень много это вообще ниочем Проблема не в гигабайтах, а в неоптимальных запросах dax к бд, неоптимальных индексах, неправильных настройках самой бд, несоответсвующим задачам оборудовании, отсутствии здравого смысла в настройках журнала базы данных в частности и здравого смысла применительно к настройкам системы вообще , кривых доработках и т.д. и т.п. ищите узкие места, думайте, оптимизируйте. резать на таких объемах проводки это всё равно что отрезать голову при головной боли |
|
|
За это сообщение автора поблагодарили: Vadik (1), ivas (2), eugene egorov (2), IvanS (1). |
12.04.2017, 23:15 | #23 |
Участник
|
Сказать много или мало можно только посмотрев на железо на котором все это крутится.
|
|
13.04.2017, 21:29 | #24 |
Участник
|
Цитата:
Интересно было бы посмотреть объем других таблиц например InventDim, InventSum, Cust/Vend/Trans/TransOpen. А в целом нужно конечно видеть хотя бы топ 25 тяжелых запросов и знать конфигурацию SQL серверов. Ах, да, чистить быстрее всего с помощью TRUNCATE TABLE https://msdn.microsoft.com/ru-ru/library/ms177570.aspx
__________________
aLL woRk aNd nO JoY MAKes jAck a dULL Boy Последний раз редактировалось ivas; 13.04.2017 в 21:35. |
|
13.04.2017, 22:58 | #25 |
Участник
|
Цитата:
Сообщение от ivas
Ах, да, чистить быстрее всего с помощью TRUNCATE TABLE https://msdn.microsoft.com/ru-ru/library/ms177570.aspx
__________________
любитель портвейна и снов с прокисшей капустой в усах |
|
14.04.2017, 00:43 | #26 |
Участник
|
Тоже неплохой вариант по производительности но после команды DROP TABLE/DATABASE теряется структура таблицы, а отчистка подразумевает удаление только данных
__________________
aLL woRk aNd nO JoY MAKes jAck a dULL Boy |
|
14.04.2017, 10:06 | #27 |
Участник
|
Цитата:
Сообщение от db
330 гб это не то что не очень много это вообще ниочем
Проблема не в гигабайтах, а в неоптимальных запросах dax к бд, неоптимальных индексах, неправильных настройках самой бд, несоответсвующим задачам оборудовании, отсутствии здравого смысла в настройках журнала базы данных в частности и здравого смысла применительно к настройкам системы вообще , кривых доработках и т.д. и т.п. |
|
08.06.2017, 22:34 | #28 |
Участник
|
Ко мне приходили слухи, что IDMF будет кусочком нового варианта Миграции данных при апгрейде с AX2012 на AX7.
Т.е. IDMF режет все транзакции в AX2012, а потом DMF экспортит/имопртит оставшееся в AX7. Но опять же, это все слухи. Посмотрим что нам предложат для Апгрейда данных на AX7. |
|
09.06.2017, 21:42 | #29 |
Участник
|
Проблема в отсутствии мысли у "архитекторов системы" о типовых "объемах", работе бизнеса "в реальном времени" и "физическом смысле" транзакционных вычислений по всей истории от "царя гороха".
И если к датским основателям "маленькой бухгалтерской программки" вопросов с текущего "уровня развития" особо и нет, то авторов DMF можно было бы и заставить лично "мигрировать" любое "живущее" (хотя бы лет несколько) решение.. |
|
11.06.2017, 21:05 | #30 |
Участник
|
У меня одного ощущение, что такую тему я уже читал? Такое ощущение, что подняли какую-то старую тему, просто поменяли даты? Даже ответы как "под копирку". И снобизм в отношении размеров таблицы точно такой же, что печально К сожалению, поиском не нашел в форуме...
Относительно приемлемое решение: Разделить базу данных на 2: рабочая и архивная часть. Принять волевое решение, что все данные, созданные, скажем, более 2 лет назад - это архив и тупо перемещать их в архивную базу. Формально, по дате создания без какого-либо дополнительного анализа. Если в каком-то конкретном случае понадобятся архивные данные в рабочей базе, то по соответствующему документу вернуть данные из архива в рабочую базу. При очередном архивировании эти данные снова будут удалены в архив Размер таблиц 330 ГБ на одну таблицу - это много! Не с точки зрения оптимизации запросов, а с точки зрения администрирования таких таблиц. Создание полей, создание индексов, переиндексация, создание backup - все это будет чудовищно тормозить на таких размерах ---------------- Только что обратил внимание, что тема двухмесячной давности. Но снобизм в отношении размеров - постоянно возникающий мотив... Как только кто-то заикнется, что размер большой и приведет размер таблицы/базы в байтах, так тут же кто-то "встрянет" на тему, что это немного...
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... Последний раз редактировалось Владимир Максимов; 11.06.2017 в 21:15. |
|
13.06.2017, 21:59 | #31 |
Участник
|
Цитата:
1. всех "старых добрых проверенных" контрагентов "в архив" 2. "постоянный ассортимент" номенклатур "в архив" 3. за два года так и не "списанные" полностью проводки (те же приходы на склад) "в топку" и пусть главбух возрадуется "излишкам" инвентаризации (большая часть которых после такого решения и до "первого пересчета" физически не доживет) 4. все формы и отчеты не должны из архива данные выводить ... В итоге "исправляйте... это же ошибки... работать же нельзя... да вы нас не правильно поняли... очевидно же не вообще все zzzzz таблиц "в архив"... конечно же не все "возращенное" из архива должно обратно "при очередном архивировании" помещаться, раз мы это обратно вернули значит нам оно нужно.. пользователи не будут "смотреть и возвращать только действительно нужное" из архива.. есть же какой-то более дешевый "аппаратный" архив на уровне СУБД который сам все автоматически.. а докажите, что задавали вопросы.. мы не помним, что разговор был.. вы же профессионалы должны были.. какие такие доп. требования.. бюджет фиксирован... все консультанты непоймикогопонабиралинаработупродаютвтридорога )) и т.д." Тема действительно регулярно "всплывает", т.к. "от версии к версии" десятилетиями ничего не меняется и базы растут . Как только будут конкретные критерии "архивирования", запилить "схлопывание истории" по транзакционным таблицам в "начальный остаток" дело и посильное и тестируемое... жаль вендор не торопиться это сделать сразу для всех |
|
|
За это сообщение автора поблагодарили: Dreadlock (1), Vadik (1). |